Hi all,
With this posting I hope to start a little discussion about our use of
exceptions in VIFF and in particular what we should expose to the user
in case of exceptions. I would like to propose that we include two
messages when throwing exceptions from within VIFF:
1) a short description of the problem, understandable by non-programming users
2) a more detailed and technical message
The short description is nice because users, e.g. a millionaire or an
administrator of a double auction, don't like messages like "Some
exception occured". On the other hand, they don't like technical info
such as long Python stack traces. This is especially true if they are
not Python programmers :-) I guess the typical user would prefer a
concise message like "Exception: The disk is full.", well-knowing that
he can consult the log files for further details.
The second message is nice because it can contain detailed info about
the problem that cannot otherwise be obtained from the stack trace.
This could e.g. include string representations of the data that caused
the problem. Such info is irrelevant for the normal user, but will be
suitable for logging and for sending to the VIFF developers for
debugging.
Of course, sometimes it makes sense to supply just a single message.
I've used this way of splitting exception messages into two parts
before (in Java), and in my opinion, it results in easier debugging
and a system with better feedback to the user in case of exceptions.
Any other opinions about this?
---
Another question is how this could be implemented in VIFF. As far as I
know, exceptions in Python take an array of arguments, so we could
define the first to be the user message and the second to be a
detailed msg. But how do we then distinguish exceptions with nice user
messages from other exceptions? One way could be to use a custom
exception class that has a userMsg and a detailedMsg field:
raise NiceCustomException(, )
or simply
raise NiceCustomException()
if there is no need to distinguish. Further, if we let the
NiceCustomException have room for an inner exception, we have the
opportunity to intercept an exception from somewhere else and equip it
with an appropriate user message, e.g.:
try:
externalLib.doComplicatedDecryptStuff()
except BadPaddingException, inst:
raise NiceCustomException("Could'nt decrypt, wrong password?", inner=inst)
Again, this will allow the programmer of a VIFF-based application to
expose the user to a short and descriptive explanation while keeping
access to all detailed info about the problem that has occured. When
we use the custom exception solution, he will also be able to
distinguish between an exception with a nice user message and, say,
some unpredictable and hairy RuntimeException where the user is most
happy knowing only that "Some exception occured".
Regards,
Thomas
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
