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/
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
