Should exceptions be raised higher up or lower down or both?

Question

When calling some function in a Python application, the function often calls functions deeper down which again call functions deeper down, etc. It is easy to unknowlingly pass a bad value to the top-level function which will cause a failure further down. Naturally, the parameters should be checked and exceptions raised with helpful error messages. But where should this ideally be done, and why?

1. As high up as possible (error messages are probably easier to understand since they're closer to the user)
2. As low down as possible (exception messages are closer to where the errors would actually occur, and the checks may be simpler since they probably don't depend on some obscure combination of input values, but the messages and variable names might be so far removed from the user that the only way of knowing what actually must be changed in the top-level call is to inspect the source from top to bottom)
3. Both

Answer 1

Throw an exception the moment that you know your code isn't going to be able to recover from an error condition on its own (i.e. without user intervention).

Example: Your code determines that a supplied path to a disk file does not exist, and the code cannot proceed without a good path. Throw at that moment, wherever it happens in your code.

Always include in the error message enough information to diagnose the problem. Preserve the call stack; you'll need that to get back to the place in the code where the exception was thrown. The call stack will tell you not only where the throw occurred, but every function or method call that took place up to the moment of the throw.

The whole point of exception handling is to provide the ability to throw an exception anywhere an unrecoverable error condition happens.

Answer 2

Python has 2 coding styles:

1. Easier to ask for forgiveness than permission (EAFP): This coding style is based on head leap and try. So you use a lot of try-except blocks instead of if statements

   try:
       ham = spam.eggs
   except AttributeError:
       handle_error()
   

2. Look before you leap (LBYL): This method is preferred in languages like C and Java.

   if hasattr(spam, 'eggs'):
       ham = spam.eggs
   else:
       handle_error() 
   

   That is not the Pythonic way for some developers and the docs explains some key points:

   In a multi-threaded environment, the LBYL approach can risk introducing a race condition between “the looking” and “the leaping”. For example, the code, if key in mapping: return mapping[key] can fail if another thread removes key from mapping after the test, but before the lookup. This issue can be solved with locks or by using the EAFP approach.

   Java language is the contrast of Python in this manner

   (In Java) The moral of this story is simple:exceptions are, as their name impllies, to be used only for exceptional conditions; they should never be used for ordinary control flow.

This answer has a good demonstration on when to use EAFP and when not.

If you are using python, it is normal to use exception instead of if-conditions and handle the situation according to the exception you catch. That will make you use exception on every level of the code. So that leads you to the answer 3, or the option 4) any level that you can use. If execution time is very important, than you can check above SO question.

Answer 3

Short answer is "Both".
You might want to trap "errors" early on, throwing out bad data (although whether that's an "Exception" is debatable). You definitely want to throw exception when things go "badly wrong", and that tends to be lower down in the layers of code.

A question to consider before throwing an Exception - "Then what?" If your code throws an exception, what is someone else's code going to do about it?

This is why there are lots of Exception classes, rather than just an "Error" object that happens to have some [arbitrary] error "Number" associated with it.
If a piece of code can catch your exception, analyse what went wrong (perhaps from what's passed in the Exception) and then recover from that the situation, all without the User knowing anything happened at all, then you're on to a Winner. Use specific Exception classes that can be caught and handled separately.

If all you ever want to do is dump the exception into a log file (never show the whole thing on screen!) then re-using the supplied, basic Exception classes is probably all you'll ever need.

Answer 4

The answer is "3. Both." Every layer offers a specific interface, and this interface has specific constraints. These constraints should always be enforced by means of validation. One layer is not supposed to do another layer's validation, nor rely on another layer to do its validation for it. If you move a layer into a different system, it should still be able to function.

All unexpected exceptions (exceptions about things that normally should not happen) indicate a bug in the code that threw the exception, except "InvalidArgumentException", which indicates a bug in the code that called the code that threw the exception.

So, if layer A invokes layer B, and layer A contains a bug causing it to pass wrong information to layer B, but layer B does not do its own validation, then layer B will throw some "FailedToDoWhatYouAskedMeToDo" exception, at which point you will naturally start looking for the bug in layer B. If layer B does its own validation, then layer B will throw an "InvalidArgumentException" instead, thus pointing you to look for the bug in layer A.

So, if you do not have every layer do its own validation, then you will be constantly confused about where a bug is. You will often have one layer which is throwing an exception for a bug which exists in another layer, which is another way of saying that you may have a bug somewhere and expect a different layer to find it. This is chaos, and to be avoided at all costs.

There is a subtle point which is perhaps worth mentioning in the case of Python, because as far as I know, Python is a bit inconvenienced with respect to distinguishing public vs. private stuff. Normally, you may avoid duplication of validation within a specific layer, by having only public functions do validation. In other words, private functions of a layer do not need to be repeating validation that has already been done by public functions. But if all functions are public, then all of them need to do validation.