[This thread follows on from the 'RelaxWarnings and RelaxErrors' thread]
On Wed, 2006-08-16 at 17:54 +1000, Edward d'Auvergne wrote:
Because they do two very different things. Warnings communicate a
potentially dangerous state to the user without affecting program flow.
Exceptions communicate some event (usually unexpected) that needs to be
dealt with by the program. This often requires that program flow be
disrupted in quite specific ways, so that the affected opperation can be
backed up and tried again. Exceptions only become errors that the user
should know anything about if the program has no way of dealing with the
exception. The systems are incomatible because they need to achieve two
very different things. That said I don't much like the Python warnings
system, and I suspect yours will serve relax's purposes much better.
Where I dissagree is with an exception system that tries to work in the
same way.
I like the argument - warnings can be turned into errors but errors
always remain as errors. That solves the original question (the
ability to change errors->warnings and warnings->errors) posed at the
start of this thread
(https://mail.gna.org/public/relax-devel/2006-08/msg00052.html).
When you talk about the warning system I attempted to implement, are
you talking about the system in
svn://svn.gna.org/svn/relax/branches/nan_catch_test or
svn://svn.gna.org/svn/relax/1.2? In the 'nan_catch_text' branch I've
used the Python warning system which is ugly and bizarre. In the 1.2
line I've created RelaxWarning classes with __call__() methods which
define the behaviour of the warning (I'm assuming this is the one
you're talking about). The Python warning system may be the way to go
though as there is a mechanism to scale warnings into errors (although
it may need a lot of fine tuning to fit with the RelaxError system
based on Exception). I can't see a way of turning the
RelaxWarning.__call__() function into an Exception though.
Yes, I meant the RelaxWarning system in the current 1.2 line, no the
Python warnings based system in branches/nan_catch_test - sorry for the
ambiguity. Though as I discuss below, I think the Python warnings system
might also make a reasonable alternative.
The non-Python warning system would however be difficult to escalate
into an error. Then again using the Python warning system would also
be complex due to it's non-trivial implementation.
I think it can be done either way, both have disadvantages. For the
non-Python system, it will require something like:
if pedantic:
raise RelaxError, msg
in the RelaxWarning.__call__() function. The disadvantage here is that
the error will be raised from the warning, not from the point in the
code where the warning was trigered. Therefore the traceback will not be
as clear as it might be. There is also a risk that the RelaxError might
be accidentally caught elswhere in the code, and misinterpreted. One way
around that would be to use a specific class of Exception for upgraded
warnings (RelaxPedanticError, eg.). Of course this could be subclassed
to give more specific behaviour, and could be caught if UI issues
demanded.
Escalation of Warnings in the Python system should also be quite easy,
by setting appropriate filters at a high level in the code
(prompt/interpreter.py might be the spot, or maybe even the relax main
script?). The code would look something like:
if pedantic:
warnings.filterwarnings('error', category=RelaxWarning)
else:
warnings.filterwarnings('always', category=RelaxWarning)
Then all warning classes that are subclasses of RelaxWarning will be
raised as an exception if pedantic, otherwise the warning will be
printed and execution will continue. This approach has none of the
drawbacks of the the custom warning system described above, but does
suffer from the general obscurity of the python warnings system. I
suspect it should be possible to subclass from BaseError as well,
meaning that exceptions raised by escalation of a warning will be easily
treated by the UI specific try statements and will have the same nice
debuging features as we put into the other RelaxErrors.
I guess I'm begining to favour the Python warnings system, because I
think it will lead to clearer results for the user, even though it might
make life a bit more complicated for the developers. This is not a
strong preference, though, so if anyone else feels strongly otherwise,
I'm happy either way.
Chris
RelaxWarnings