3 ms·
I'm not bashing your idea, but throwing an authentication exception covers this almost entirely. See, the calling code probably can't correctly proceed unless
by politician 15y ago
I'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.