Re: The Evolution of the Lowly Debug Statement

Each error message should be unique enough to uniquely identify the code which threw the error, and to permit that code to be found with a simple search for the error message itself.

Not necessarily. One of the most common error messages is about not being able to open a file. If I can't open a file, I don't care at all where in the code the error occurs, only two things are relevant: which files was tried to be opened, and why did it fail.

Furthermore, I think that one shouldn't bother the user with line numbers where problems occur. Line numbers are fine for debug messages, as debug messages are (mostly) for the developer. Error messages are for the user, and (s)he can give diddle twit where the error occurs. Take for instance your cell phone. If you dial a number, and you cannot connect, you expect the phone to show you the number it tried to connect to, and the reason the connection failed. You don't really care on which line of the code this error message is on.

Comment on Re: The Evolution of the Lowly Debug Statement

Replies are listed 'Best First'.

Re^2: The Evolution of the Lowly Debug Statement
by Jenda (Abbot) on Nov 10, 2006 at 18:38 UTC

If all you have is the filename and reason of failure then you might spend hours trying to find out why the heck did you try to open the file at all. The unability to open a file doesn't have to be an administration problem, a permissions issue or something similar. You migth have an error somewhere in the code that generates the filename and then it might be very helpfull to be able to tell which open statement failed.

OTOH, it may be good to display only the "basic" stuff to the user and log the details into a file. Sometimes this is not possible and then it may be fine to include information that will be useless to the user directly, but may come in handy when the user calls that he just got an error that something went wrong on some silly line 12345.

Jenda
Support Denmark!
Defend the free world!

[reply]