Similarly, VMS's exception handling mechanism gives each error a
two-bit severity level ( Informational, Warning, Error, Severe ),
a "facility" field ( equivalent, in this discussion to a program
or a module. ) and a specific numeric error code.
( Numeric codes get mapped to error-strings through a separate message
facility. )
VMS implements more of a "signal handling" style of exception handling,
than Python's "abort and throw" style. Each stack frame can contain the
address of an exception handler, so they can be nested. And each
handler can choose to ignore the error, fix the error and continue,
do something and return to the error-signaling function's caller,
change some fields in the error-code (like changing a SEVERE level
to a WARNING,for example) and resignal to an outer handler, or resignal
it unchanged to another outer handler. ( This is from ancient memory,
so forgive me if I missed anything. )
Since an error doesn't necessarily abort anything, error signaling
( at an INFO or WARN level ) is used in VMS for lot's of debug or
verbose logging type messages. To run in quiet mode, you just turn
off display of INFO or WARNING level messages.
Filtering of errors is the usual way of processing: your handler
will catch most errors, but the ones you are not prepared to handle
are just resignaled to the next level. At the very bottom is the
error handler in the shell, which by default prints out the stack
trace info and abort the program ( if level is ERROR or SEVERE ).
> Grouping collections of related errors into categories is a powerful idea,
> particularly if you can write exception handlers that catch all errors
> belonging to a particular category, rather than writing an exhaustive list
> of error names. Eric Allman wrote an exception system in which error names
> are strings, and error handlers can use glob-style pattern matching to
> identify categories of exceptions. In Common Lisp, an error name is bound
> to a subclass of Condition (rather than a string), and an error value is
> an instance of this class (rather than a name, value pair). Errors are
> grouped into categories using inheritance, and an error can belong to several
> disjoint categories by using multiple inheritance. An error handler
> specifies the classes of the conditions it wants to catch.
>
Filtering of errors in Python is possible, since the signals and their
parameters are represented as strings, but it is awkward, because:
(1) there aren't any consistant conventions on the format of those
strings, and
(2) the syntax for the non-typical case is confusing.
For example: suppose you want to catch all errors from a particular
module, or all errors from a particular file? Both doable (I think),
but not something I could attempt without first experimenting a bit.
i.e. there is not an obvious non-contingent solution.
I could think of a number of ways to 'fix' python exceptions - but
I'm not sure which is the most practical, least radical and most
compatible modification. Maybe simply documenting some conventions
on Exception Names and the auxillary strings used in raise would
be enough. ( what DO you call the 2nd arg to raise ? ). Maybe not.
Anyway: one topic in OO and SE circles has been why OO programming
languages have not "solved" the soflware reuse problem. From some
of these python-list discussions, I would propose that most of the
language features in Python and most other OO programming languages
are simply not strong enough to provide robust reusable modules
BY THEMSELVES. That is: all of the language FEATURES all require
a large matrix of USE CONVENTIONS that are usually not defined IN
the languages itself. ( And I would guess that if you actually made
all of those conventions LANGUAGE REQUIREMENTS, that you would end
with something so constrained and pedantic that it would be rejected
by most programmers.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics