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