[Tutor] Why subclassing exceptions?

[Alan Gauld]

On 28/09/11 10:23, 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).

That doesn't make it good :-)
You can write a lot of code without using functions or classes or 
exceptions. But it doesn't mean it couldn't be improved by adding
those features.

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

If all you can do is scream out then raising an exception is mostly a 
waste of space. Exceptions are there to be caught and handled. Error 
messages are where we should scream out, not the exceptions themselves.

> In fact, I use exceptions only when I can't write an ``assert``

But asserts should be used in debugging only. They are dangerous things 
to rely on in production code. Unless you are using assert in a wider 
context than literal assert() calls?

> > 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.

Using asserts is a form of the if/else type error handling that plagued 
programmers during the 70's,80's and even into the 90's (thanks 
Microsoft!) and which try/except style exceptions were, in part, 
designed to eliminate. The problem with "assert" and if/else style 
checking is it greatly complexifies the code structure and makes it much 
harder to see the "happy path" flow. Exceptions allow us to code in the 
same way we write use cases during analysis:

Precondition check
happy path sequence
exception cases
postcondition check

That makes for more readable and therefore more maintainable code.
It also means we can add new exception handlers as needed without 
interfering with the core algorithm structure. (It also means the core 
algorithm can be optimised for speed without all the explicit if/else 
checks going on, but that should be considered a free bonus not a reason 
to adopt exceptions!)

And finally, as you suggest, when code gets reused (and often that 
happens to code we didn't expect to reuse!) exceptions make for an 
easier and more consistent interface for the reuser (who may be yourself!)

> Is there any reason for which you (or anybody on the list, of course)
> think I should avoid doing this?

It's perfectly possible to write code the way you are doing but it
involves multiple error mechanisms (because the standard library uses 
exceptions) and is less familiar to other programmers. If its only for 
your own use then its a moot point, it really becomes significant when 
working on collaborative projects or for reuse.

OTOH writing with exceptions takes very few extra keystrokes so why not 
just use as intended? ;-)

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/