On 8/14/06, Chris MacRaild wrote:
On Sat, 2006-08-12 at 16:01 +1000, Edward d'Auvergne wrote:
> I've implemented most of a new relax error/warning system that has
> been talked about in this and a few other threads. The changes are
> located within the 1.2 line (the new system can sit side-by-side with
> the old RelaxError system without affected program execution). The
> way these new RelaxErrors and RelaxWarnings are called is by typing
> something like:
>
> relax> RelaxBadError('Hello')
>
> This is because RelaxBadError (a test error) is a class instance and
> I've created a '__call__()' function for these simple, non-exception
> objects. Are there any features of the old system missing in the new
> that you would like added? Can you see useful new ways that this
> mailable framework can be extended? Or can you see disadvantages with
> this approach?
>
I agree that this approach gives us a great deal of flexibility when it
comes to how errors and warnings will behave. I'm a bit concerned about
some of the features of Python exceptions that we loose by going this
way, however.
So am I. I don't know if it is the way to go!
I'm a big fan of the try/except style of error managment
that Python encourages, and its not at all clear how we might impliment
that easily in the new framework.
I'm not so keen about the 'try:' system. For small programs it works
beautifully. However within relax exceptions can be quite difficult
to handle. For example handling an exception thrown by thread (in
threading mode this is a major headache that I haven't fully solved).
This will come up again if MPI is implemented. Another issue is
exception handling when there is a mixture of Python and C. It would
be useful if we could precisely define this behaviour. A grep for try
statement should show how much of a hack the try system is within
relax. If there are any useful properties of exceptions that are lost
though - then it may not be worth dropping the system (unless we can
mimic anything that seems useful).
This means that while its easy to
generate classes of error with specific and complex behaviour, its not
easy to override that behaviour in a specific context.
The __call__() function can be defined specifically at runtime within
the 'error.py' file. But if necessary any part of relax can override
it with a new function (although that should probably not be done).
Ultimately I guess I'm looking at the distinction between an error (or
warning) and an exception. An error or warning means something has gone
wrong that the user needs to know about. An exception is just another
programing tool for controling how our programs respond to events. As an
example, consider the way python iterator objects work: they iterate
through a series of objects, returning them one a time. When they run
out of objects, they raise a StopIteration exception. Clearly this
exception does not indicate an error that the user needs to know about,
or even an unexpected event (most iterators will stop eventually).
Instead code using iterators needs to use an appropriate try/except
construct to catch the StopIteration and respond appropriately. The nice
thing about exception behaviour in this context is that this try/except
can be at any level in the code - it doesn't need to sit in the same
function that directly interacts with the iterator. The message that the
iterator has run out of objects gets passed to the appropriate place
without any extra code from us. Thus we get much simpler, clearer code.
This issue that needs to be dealt with, then, is how to have the sort of
error handling at the users end that we want (errors and warnings that
can be up- and down-graded, rich debugging behaviour, etc) as well as
having good exception handling at the code level, for both builtin
Python exceptions and specific relax exceptions.
We could leave the Python exceptions as is (the try statements usually
end in 'expect: raise' so that these are always raised) while having
relax defined errors which aren't actually exceptions. It would be
possible to define all of the necessary behaviour of Exception objects
within the RelaxError objects while avoiding 'raise' statements.
Another reason is that a RelaxError based on the Exception class is
difficult when scripting. The try statement will catch it and ignore
it, but the execution of the script cannot be continued. Then again,
is there a situation where ignoring errors and continuing program
execution would be useful?
In addition to the options we've already considered, there is the
possibility of coding appropriately rich behaviour into a replacement
function for sys.excepthook. This is the function that is called when an
exception is not caught by an appropriate handler. It's default
behaviour is to print the traceback and display the error. It is passed
both the exception class and the specific instance that was raised, as
well as the traceback object. This should be enough to get some quite
rich behaviour without too much hacking, I think.
I wonder, what is more important - the 'raise' semantics, the
Exception objects, and all the related behaviour or simply the
printing out to stderr? All the ancillary relax specific behaviour
can be implemented in both systems. But what are we trying to really
achieve with the RelaxErrors?
Edward
Re: RelaxWarnings and RelaxErrors.