From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,699cc914522aa7c4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wns14feed!worldnet.att.net!208.49.83.154!uns-out.usenetserver.com!news.usenetserver.com!pc03.usenetserver.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Structured exception information References: From: Stephen Leake Date: Wed, 17 Jan 2007 07:10:24 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:DUDQm5IZYgDEglgzJ9bN5r/DOjQ= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: dc06645ae1231759e00d402879 Xref: g2news2.google.com comp.lang.ada:8221 Date: 2007-01-17T07:10:24-05:00 List-Id: Maciej Sobczak 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