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!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!208.49.83.154.MISMATCH!uns-out.usenetserver.com!news.usenetserver.com!pc02.usenetserver.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Structured exception information References: From: Stephen Leake Date: Fri, 19 Jan 2007 04:47:28 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:akPEPmLzlgdR3UTIymbpwtlafI4= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 63d5845b093b3759e00d426244 Xref: g2news2.google.com comp.lang.ada:8319 Date: 2007-01-19T04:47:28-05:00 List-Id: Maciej Sobczak writes: >>>> 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? > > Doesn't feel as type-safe as advertised. But you have not given an actual example where a string is not a type-safe solution to the actual problem at hand. The only example you have given is "present the error to the user". In that case, a string is precisely the correct type. >>> - 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: > [...] > > Sure. That's why there are more JavaScript programmers than Ada programmers. I don't follow. Strings are perfectly valid Ada constructs. Why does the code to build the string not feel like Ada to you? >> 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; > > Of course, with similar routine for dismantling all this in the > handler. You have not said _why_ you need to dismantle this information in the handler. What, _exactly_, will the handler do with the separate bits? > Still, that's not what I expect from Ada. Lots of people expect lots of things. Sometimes, those expectations are unreasonable, and should be changed. That's what I'm trying to explore here; I think expecting anything other than a string for exception data is unreasonable. So far, you have presented no case to show I am wrong. >> 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". > > That is a reasonable approach and will work fine most of the time, When will it not work? I have never encountered such a case. > but it does not explain the lack of a language feature that is taken > for granted in other languages - and coming from another language, I > find the lack of structured exception information as a defect, even > though I realize that I can easily work around it. The point is that > I should not be forced to work around anything. If you look into the details of "structured exception handling" in other languages and implementations, they have bugs, and fundamental flaws in design. That is why Ada did not go that way. Ada is _much_ more careful about getting the core design right, allowing fully robust and safe implementations of _all_ features, especially in multi-tasking and multi-processing environments. So if you find yourself fighting Ada to do something, you need to step back and think more carefully about _why_ you are doing it that way. Ada is telling you it is inherently unsafe. -- -- Stephe