Handling server exceptions with Breeze SaveChanges () method

Question

I am using Breeze with Angular and EF 6 in my project and I have a form where I perform CRUD operations.

I have this entity called: Car2Sale which is a many-to-many table (Id, CarId, SaleId). Id is the PK for this table while CardId and SaleId are FKs to their associated tables and they are grouped together in a unique index. (CarId, SaleId).

When I want to add a new Car2Sale entity with a CarId and SaleId that already exist in the database I get this error on server side: Violation of unique constraint... at this method:

[HttpPost]  
public SaveResult SaveChanges(JObject saveBundle)  {             
    return _repository.SaveChanges(saveBundle);  
}

which is correct because I wanted to prevent the user from introducing similar keys in the same table.

On the client side I receive the error in the

entity.entityAspect.getValidationErrors();

and I display it using Toastr.js.

I was wondering what is the best practice to do exception handling in the SaveChanges() method in this case on the server side.

I was thinking about using a try catch on the server side and return a SaveResult of my own, like below:

[HttpPost]  
public SaveResult SaveChanges(JObject saveBundle) {            
    SaveResult myResult = null;  
    try {  
        myResult = _repository.SaveChanges(saveBundle);  
    } catch(Exception ex) {  
        Logger.Log(ex.toString());  
    }   
    return myResult;  
} 

Many thanks

Answer 1

My main objection to your particular approach is that you're swallowing the error and returning what appears to be a "happy" SaveResult to the client. The BreezeJS client will assume that the save succeeded and will update your cached entities accordingly. That's not a good idea!

You can certainly catch it on the server-side and might want to do so in order to reshape the error response. I think that I would do so INSIDE the repository as I'm disinclined to have persistence logic in my controllers. Encapsulating that stuff is the raison d'etre of the repository/Unit-of-Work pattern.

It's not clear to me how this helps you on the client side. You still need to send the error to the client and have the client do something reasonable with it.

You might want to look at the Breeze Labs SaveErrorExtensions for ideas about interpreting errors on the client. To my mind, the hard thing is communicating actionable intelligence to the user. That's a business/design decision that we can't solve for you. We can give you the information; you have to make sense with it.

HTH.