[Tutor] Why subclassing exceptions?

[Steven D'Aprano]

Mac Ryan wrote:

> I have to say - however - that even after a few years of python
> development I seldom use exceptions that way: in fact I can only
> remember having subclassed error classes once, when I wrote a library
> that was intended to be used by third-parties (for the exact same
> reasons that you exemplified).

You don't have to subclass exceptions. You can raise exception classes 
that already exist. Most of the time, that's exactly what you should do.


> In all other cases (code that doesn't expose an API to third parties)
> I consider that either my program works (and thus it can handle all
> possible situations) or it does not, in which case - given that nothing

If your program can handle ALL possible situations, that would be a 
first for any program written in any language in the entire history of 
computing. Well done!

<wink>


> should silently fail - I'm happy for it to scream out loud with a raise
> BaseException('<useful-debug-message-here>').

Well here's the thing. It's your program, you can make it do anything 
you like. If you want it to raise TooMuchCoffee exceptions, go right 
ahead. But there are standard meanings for exceptions in Python, and you 
are ignoring them.

The error message gives you a human readable message. The exception type 
tells you the category of error. You are ignoring or abusing that 
information channel by mis-using BaseException. Regardless of whether 
the exception gets caught or not, the exception type gives the user 
valuable information.

Think of it this way: exceptions are like a great big control panel with 
warning lights. There's a warning light for "fuel warnings", another one 
for "temperature warnings", a third for "did you remember to lock the 
front door when you left home", and so forth. Each light can blink in a 
pattern, which a human being can look up in the manual to see exactly 
what sort of fuel warning: "no fuel in engine 3", say. But even without 
reading the detailed message (which sometimes can be fairly cryptic), 
the mere fact that it's a fuel warning gives you a lot of useful 
information: it's a *fuel* warning, not a flat tire.

You are always using the same "miscellaneous unknown warning" light, for 
*everything*:

"miscellaneous unknown warning: out of fuel"
"miscellaneous unknown warning: doors left unlocked"
"miscellaneous unknown warning: temperature too high"
"miscellaneous unknown warning: out of milk"



> In fact, I use exceptions only when I can't write an ``assert``
> statement concise enough. In the original code to which you initially
> reacted I used an exception simply because it was more concise to put
> it under the else clause rather then writing an ``assert`` statement
> with all the if/else possibility it would have needed.


If you are using asserts for data validation, then your code is broken. 
The caller can disable every single assert, and hence remove your data 
validation, by simply passing a command line switch when calling your 
program.




-- 
Steven