6

Suppose I have a controller that loads a file and hands it over to the processing.

  • Should I handle the exception in the file loader and return Null if something is wrong, or should I throw the exception and handle it in the controller?

  • Without the file the rest of the program can´t work. Where should I handle a exception that shuts down the program properly?

I want to shut down an Android application properly.

2 Answers 2

Reset to default
6

In layman's words:

  • You should not return null.
  • The exception should be handled in the top-most layer.
  • The program should not terminate, but give feedback to the user, unless it is a Unix style command line program where it's ok to terminate after showing an error message.
  • By definition no exception is fatal and each one can be handled.
  • Errors are fatal and cannot be recovered from.
  • Exceptions and errors are not the same.
5
  • 2
    In practice, as opposed to definition, the difference between errors and exceptions is rather fuzzy. You can sometimes recover nicely even from a null pointer exception, which despite its usual name is normally considered an error. My best definition is that an "error" is an "exception" that takes too much work to catch; easier to stop it from happening than to recover from it.
    – RalphChapin
    Commented Oct 3, 2012 at 14:14
  • 3
    In Java, some events cosidered errors (not Exceptions) are InternalError, OutOfMemoryError, StackOverflowError, UnknownError, etc. These situations prevent the virtual machine to even continue to run the application. These are surely conditions a program cannot recover from. It's like the program is a bus, an exception would be a tire exploding. An error would be the engine suddenly disappearing.
    – Tulains Córdova
    Commented Oct 3, 2012 at 17:28
  • They are defined as errors, and with very good reason. Still, they're just at one extreme of a continuum. I've wanted to catch OutOfMemoryError on occasion, and I recall a question on SO about how to do that reliably. (I don't think there was a good answer.) And people (though not me) complain about checked exceptions, meaning they want to treat them as errors. This is something of a fine point, and the terms "Exception" and "Error" do have (fairly) clear and distinct meanings.
    – RalphChapin
    Commented Oct 3, 2012 at 18:28
  • There's absolutely nothing wrong with catching an exception and returning null if that is appropriate for the situation. One example might be a method that returns a file object, but returns null if the file does not exist. The important thing is that the caller expects a null return value and handles it correctly.
    – Ian Goldby
    Commented Oct 11, 2016 at 10:00
  • "Exceptions and errors are not the same." Unfortunately the reality is that mainstream languages, libraries, frameworks etc raise exceptions in response to error conditions and we have to live with this.
    – Ian Goldby
    Commented Oct 11, 2016 at 10:08
0

Exceptions should go up until they reach the layer where you need to take care of them (i.e. catch them and act accordingly).

In your example, it seems you need to load a file; if the file is not found or is corrupt, you want to close the application. In this case, it seems that you should catch the exception at the outermost layer (loader -> controller -> ... -> entry point -- catch here), present an error message to the user, and quit. Catching the exception anywhere else will only make your code more convoluted and difficult.

This makes sense if the file is not something that depends on the user and the user cannot do anything to fix the file if it is wrong or missing.

On the other hand, if the file is one that is chosen by the user (or can be), you should show an error message to the user, and then give the opportunity of finding the right file instead of quitting.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.