3 ms·
I don't think that this article focuses on the right problem at all. The real problem in my eyes is that the semantics of 'null' is not agreed upon. It can mean
by strictfp 15y ago
I don't think that this article focuses on the right problem at all. The real problem in my eyes is that the semantics of 'null' is not agreed upon. It can mean anything, including but not limited to:
* Wrong username
* Wrong password
* Login procedure aborted due to external factor
* Programming error
This causes a headache, since the client might forget to check for the magic value 'null' and the symptom might therefore accidentally be deferred to any later time.
Instead of using a callback method, why not just return an instance of some more sophisticated class, i.e something like this:
public AuthenticationResult authenticateUser(User user) {
...
}
with a possible usage:
AuthenticationResult authResult = authenticateUser(user);
if (authResult.failed()) {
notifyUser(authResult.getFailureReason());
}
If the client then tries to use a failed AuthenticationResult as a successful one, or use a successful AuthenticationResult as a failed one, the programmer is free to throw any informative exception. Example:
class AuthenticationResult {
...
public FailureReason getFailureReason() {
if (!failed) {
throw new IllegalStateException("you cannot fetch a failure reason from a sucessful AuthenticationResult!");
}
}
public AuthToken getAuthToken() {
if (failed) {
throw new IllegalStateException("you cannot fetch a auth token from a failed AuthenticationResult!");
}
}
}
If one instead would use 'null' as a magic value for 'auth failed', the dreaded NPE would show up instead!
- politician 15y agoI'm not bashing your idea, but throwing an authentication exception covers this almost entirely. See, the calling code probably can't correctly proceed unless authentication was successful, and there's no chance that the caller can simply forget to handle an exception -- at the very least, it'll hit a top-level exception handler and/or crash the program.
- strictfp 15y agoThat is another viable strategy if you don't want to handle the login failure in any graceful way.
- politician 15y agoExceptions are not a crash-or-nothing proposition. The idea is that the caller should handle them at the earliest point in the call-stack that can do something reasonable about the problem. Also, let me clarify that I don't believe that exceptions should be used as the only way to return values from a method in languages that support them. They are simply a tool with certain properties (among them, the ability to be more difficult to ignore, the topic at hand).
- strictfp 15y agoI generally find that one should avoid using exceptions for flow control. They have their usages, but they should in my opinion only be used when they really shine - when you have multiple levels of callers between the detection of the error and the handling. This was not the case in the simple example, and so I chose a return value instead of an exception.