Question

Suppose I have a method that must return an object (say from a database layer) and takes as input some info about the requested object.

In the normal case, the method should return the object. But what happens if the precondition of the methods are not fulfilled by the caller; how should I (the code writer of the method) inform the caller?

Take for example the case that I should return information about the user from a db, and I take as input the username and the password. In the normal case I should return the User object. But what if the username and password are null, if they mismatch, if the password is too short… how should I inform the caller what is exactly the problem?
Normally I would have thrown an exception, but here – When to throw an exception? was suggested that it is a bad idea.
Should I put an errorDetail field in the User, or make a method checkInputData or getErrorStatus…

Answer 1

It sounds perfectly reasonable to throw an exception in this case. The method, which should be doing one thing and only one thing, is simply trying to fetch a user record from the database. If a precondition fails, give up. If the database errors out, give up. If no user is found, give up. Let the calling code deal with the consequences.

An exception is a perfectly acceptable exit path for a method.

In the case of the precondition, it’s not the method’s responsibility to fix that. It’s the calling code’s responsibility. So throw an ArgumentException of some kind and let the calling code deal with it.

In the case of a database error, either catch it and throw a custom exception (something like an InfrastructureFailed exception) for the application to handle accordingly. Basically the application needs to tell the user that there are technical difficulties and to please try again later.

In the case of no user being found, that sounds like a failed login. Throw some kind of SecurityException and let the calling application handle it by notifying the user that the login has failed. (Don’t be more specific. For example, don’t tell the user that the username was fine but the password was bad. That’s giving a malicious user more information than you want them to have. Just say that the login failed, nothing more.)

You also mention a case of a password being too short. I imagine that’s something that should be validated before it gets to this point. In this case, that falls up under input checking for the method. So the preconditions fail and the method never even tries to get to the database. But “password is too short” probably isn’t a good error to tell a user at a login prompt. Rather, that’s for when they try to create the password.

One thing you shouldn’t do is return null or an empty user object or anything like that. This puts the onus on the calling code to check if there was an error. Exceptions are a perfectly valid way of notifying calling code of an error. A “magic object” being returned is just like any other “magic string” in code, but worse because it leaks out of the method and into other code.

Now, this isn’t always a complete rule, of course. It depends on the structure of the application. For example, if this is a web service or some other kind of request/response system then you might want to have a standard response object which would indicate failure. That assumes some application context around the method, though. And in that case you probably should still be dealing with multiple methods. The inner one (a domain logic method) would throw the exception, the outer one (an application UX-aware method) would catch the exception and craft an appropriate non-null response to the UI.

How you handle the exception is up to the logical structure of your application. But throwing and catching exceptions (keep in mind that “catching” is not the same thing as meaningfully “handling”) is perfectly acceptable behavior.