Re: Structured exception information

[Stephen Leake <stephen_leake@stephe-leake.org>]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Stephen Leake wrote:
>
>>> How can I pass some error information from the constructor function
>>> out, so that it's used when the exception is handled?
>> Why do you want to?
>
> So that the handler has more information about the error?
>
>> Generally, all you can do is report the error to
>> the user.
>
> That's what I want to do.

Then what's wrong with a string?

>> Can you give a detailed example of passing more complex information
>> that is actually used?
>
> Imagine a constructor function that calls a database or a script
> engine with the query/script provided as a parameter. Some error can
> result and I want to raise an exception. The handler might benefit
> (even if for the purpose of presenting a nice error pop-up message)
> from:
>
> - error code
> - error message
> - line number
> - character position
> - hint from the engine
> - timestamp from within the engine
> - ...

All of this can be put into the string by the routine raising the
exception:

raise Database_Error with 
   "Error " & Error_Code_Type'image (Error_Code) & 
   ": " & Time_Type'image (Timestamp) & 
   ": " & file_name & ":" & Integer'image (Line_Number) &
   ":" & Integer'image (Character_Position) & 
   ": " & Message & 
   ": " & Hint;

If you want a GUI pop-up, and it would be wrong to have the routine
raising the exception do the pop-up (which is reasonable), the
pop-up can just display this string. That's what Windex did.

I suppose if you want to put the different pieces of information into
different widgets in the "nice error pop-up", then you now have to
parse the string. With the structure I've shown, that's not hard; it's
colon-delimited. But I'll grant that is a case where more structure
than a string is desired.

As a general matter of user-interface design, I would find that
annoying. As a user of a system, the only thing I want from an error
message is either "how do I fix this myself" or "how do I report this
to the maintenance team".

In the first case, if the error is in a source file, displaying the
source file and line number, in a format that my IDE can understand,
is the best solution. That's a string on standard_output, not a GUI
pop-up.

In the second case, writing the string to a log file, and
displaying a pop-up with the full path name of the log file is a
_much_ better user interface. Make sure you can copy the file name, so
it can be pasted into an email message.

As a maintainer, I want the same thing. I hate conversations like
"what does the pop-up say in the third widget"? "no, the third widget
right to left, not top to bottom". Much better to say "send me the log
file".

> Another example - imagine that your compiler just prints
> "COMPILER_ERROR" instead of everything that it actually prints.
> That wouldn't be very funny!

The compiler prints a string! I have a script interpreter that does
exactly that. The string is formatted at the lowest level, where the
details of the error are known. Sometimes a higher level exception
handler prepends another string with source file information:

exception 
when E : Input_Error  => 
   raise Script_Error with File_Line_Column (current_script) & 
    Ada.Exceptions.Exception_Message (E);
end;

In building this system, I have never wished for more complex info
from an exception. Sometimes the string length limit is a problem, but
that's an implementation detail, not a fundamental design issue.

-- 
-- Stephe