None of the examples I have looked at for Repository Patterns include any kind of error handling.
Why is this? Say for instance I have this:
public virtual TItem Insert<TItem>(TItem item) where TItem:class,new()
{
dbContext.Set<TItem>().Add(item);
try
{
dbContext.SaveChanges();
}
catch (DbUpdateException)
{
return null;
}
return item;
}
An instance where we violate a constraint. I catch the DbUpdateException… Where would this error handling live if not in the repository itself?
For the most part, a repository doesn’t need to worry about handling exceptions. The classes that are consuming the repositories should handle that. In your example, why would want to return null if an insert error occurs? Isn’t that less clear than just throwing an exception?
For example, let’s say we want to insert a record through the repository and then print out the new ID. Assume that the insert is going to fail for any reason.
Following the pattern in your question, you’d get a
NullReferenceexception on the second line if theInsertfails. That’s a little strange. It’s more clear to see theDbUpdateExceptionon the first line. It’s also better to be able to count onInsertalways either returning a valid instance or throwing an exception.