In this particular situation, a better option may be to use LINQ's Single method, as so:

public void Update() { var user = db.users.Single(u => u.userid == id); // update the user record }

Single already does exactly what you want: it throws an Exception if there are 0 or more than 1 results matching the predicate.

At this point you can decide whether you're happy for the exception thrown by Single to bubble up, or whether you want to wrap it in one with a more useful message, or a specific type. The general pattern for this would be:

public void Update() { try { var user = db.users.Single(u => u.userid == id); } catch(SomeExceptionType ex) { throw new SomeOtherExceptionType("Useful message here", ex); } // update the user record }

(Notice passing ex to the SomeOtherExceptionType constructor here. This allows the information about the original exception to be preserved, as is usually good general practice)

As I said in the comment, the choice of how exactly you do this is probably not overly important. My advice would be to start with the simplest option- in this case allowing Single to throw its own exception- and refactor as needed.

If you find yourself with the need to display or log a more specific exception message, either wrap the exception in this method, or higher up the call chain as appropriate. The principle to where you do this should be avoiding leaking between your abstraction levels. Consider the following:

public void HighLevelMethod() { try { DataAccessClass.Update(); } catch(Exception ex) { throw new SomeKindOfException("What should I say here?", ex); } }

The message here should be at an appropriate abstraction level for HighLevelMethod . Something along the lines of "The update failed" (though ideally something a bit more useful!). The exact reason for the update to fail is hidden within Update , so for the message to be "The update failed because no user was found" would be causing a leak of implementation details between the abstraction layers. If you wanted to specify that level of detail, that message would need to go in an exception thrown by Update itself.

Likewise, only refactor to throwing your own Exception sub-class if that provides some useful information that you find yourself needing higher up the call chain. Will the code calling Update() have a different way of handling a UserNotFoundException than it would a ValidationException ? If not, then don't bother with your own Exception type.