Johan Vromans wrote:
>
> [...] As a result, error messages become utterly useless. I almost
> never see a Java program that reports "Cannot open file foo".
> Instead, it reports a java.lang.ioerrorexception and a stracktrace
> of several pages. Useless if you do not have the source, often
> even if you have.
RFC 88 shows how to solve this problem via its built-in exception
unwinding stack, which allows to you generate messages like this
when the exception is punted to the user:
UIM.1234: Can't add a new person to the database.
APP.2345: Can't update Company relationship.
DBM.3456: Trouble processing SQL UPDATE clause.
DBM.4567: Unable to write to Locations table.
IOM.5678: Can't open file ".../locations.ndx".
IOM.6789: File ".../locations.ndx" not found.
You can also display (or not) the stack trace (there's actually more
than one stack trace involved during unwinding, but that's a detail),
depending on whether or not the user has developer access (say) or
not, and include the exception stack and Perl traceback in the system
logs (or not), and include stack traceback and *other* information
that should not be presented to the user but should be presented to
the developer and the logs (or not), all as appropriate to *your*
application.
Might that help?
Yours, &c, Tony Olekshy
