Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

up vote 6 down vote accepted

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.
share|improve this answer
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 Oct 3 '12 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. –  user61852 Oct 3 '12 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 Oct 3 '12 at 18:28

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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