* question on exceptions @ 1996-11-02 0:00 Michiel Perdeck 1996-11-03 0:00 ` Robert A Duff ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Michiel Perdeck @ 1996-11-02 0:00 UTC (permalink / raw) Intro: This is one of several questions on Ada95 after reading the "Ada guide for C/C++ programmers" from Simon Johnston. I am a fan of Ada and I think that much (if not most) C/C++ programs should have been written in Ada. I have, however, not been able to use Ada as much as I would have liked. I have split my questions over a few messages so that reactions may be given to individual questions. Questions: Unlike an exception in C++, an Ada exception cannot carry any extra information besides it's own name. In C++ you can have an exception of a certain class e.g. SQL_Exception, and then put a message in an exception when it occurs. The exception handler can then use that information to write on a log-file or the like. It seems to me that this is a more flexible concept (exceptions as objects) than that of Ada (exceptions as scalar types). I hope you can convince me that I'm wrong! What do you think? Regards, Michiel Perdeck Michiel Perdeck CMG AT Finance, Amstelveen, Netherlands michiel.perdeck@cmg.nl michiel.perdeck@tip.nl ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: question on exceptions 1996-11-02 0:00 question on exceptions Michiel Perdeck @ 1996-11-03 0:00 ` Robert A Duff 1996-11-03 0:00 ` Laurent Guerby 1996-11-04 0:00 ` Michel Gauthier 2 siblings, 0 replies; 11+ messages in thread From: Robert A Duff @ 1996-11-03 0:00 UTC (permalink / raw) In article <E090uD.Kx6@tip.nl>, Michiel Perdeck <michiel.perdeck@cmg.nl> wrote: > Unlike an exception in C++, an Ada exception cannot carry any >extra information besides it's own name. Not true. In Ada 95, an exception can carry some string information. Look at package Ada.Exceptions. >... In C++ you can have an >exception of a certain class e.g. SQL_Exception, and then put a >message in an exception when it occurs. The exception handler can then >use that information to write on a log-file or the like. It seems to >me that this is a more flexible concept (exceptions as objects) than >that of Ada (exceptions as scalar types). I agree that the C++ way (which also exists in many other languages, such as Java, CLOS, CLU (I think?)), is better, because Ada restricts this information to be of type String. Also, these other languages allow an exception handler to decide how finely to control the handling -- handle all sorts of I/O errors, or just handle the file-not-found error -- whereas in Ada, this decision must be made at the point of the exception declaration(s). Also, two kinds of things are needed in Ada (exceptions and Exception_Id's), where one would suffice. IMHO, that's an ugly hack. On the other hand, type String is often good enough -- your example of a log file is easy to do in Ada. >I hope you can convince me that I'm wrong! What do you think? You're partly wrong. ;-) - Bob ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: question on exceptions 1996-11-02 0:00 question on exceptions Michiel Perdeck 1996-11-03 0:00 ` Robert A Duff @ 1996-11-03 0:00 ` Laurent Guerby 1996-11-04 0:00 ` Do-While Jones 1996-11-04 0:00 ` Michel Gauthier 2 siblings, 1 reply; 11+ messages in thread From: Laurent Guerby @ 1996-11-03 0:00 UTC (permalink / raw) Michiel> Questions: Unlike an exception in C++, an Ada exception Michiel> cannot carry any extra information besides it's own name. In Michiel> C++ you can have an exception of a certain class Michiel> e.g. SQL_Exception, and then put a message in an exception Michiel> when it occurs. The exception handler can then use that Michiel> information to write on a log-file or the like. It seems to Michiel> me that this is a more flexible concept (exceptions as Michiel> objects) than that of Ada (exceptions as scalar types). I Michiel> hope you can convince me that I'm wrong! What do you think? In Ada 95 an exception can carry a message (String), I believe this functionality was added to help logging (an example of use you give). Exceptions are not "scalar" types, look at Ada.Exceptions if you're interested in Exception_Occurence objects. If you need more information to pass with an exception, may be it's better to add a few parameters to your interface. -- Laurent Guerby <guerby@gnat.com>, Team Ada. "Use the Source, Luke. The Source will be with you, always (GPL)." ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: question on exceptions 1996-11-03 0:00 ` Laurent Guerby @ 1996-11-04 0:00 ` Do-While Jones 1996-11-06 0:00 ` Robert A Duff 0 siblings, 1 reply; 11+ messages in thread From: Do-While Jones @ 1996-11-04 0:00 UTC (permalink / raw) In article <ws9iv7n2jtu.fsf@schonberg.cs.nyu.edu> guerby@gnat.com writes: >Michiel> Questions: Unlike an exception in C++, an Ada exception >Michiel> cannot carry any extra information besides it's own name. In >Michiel> C++ you can have an exception of a certain class >Michiel> e.g. SQL_Exception, and then put a message in an exception >Michiel> when it occurs. The exception handler can then use that >Michiel> information to write on a log-file or the like. It seems to >Michiel> me that this is a more flexible concept (exceptions as >Michiel> objects) than that of Ada (exceptions as scalar types). I >Michiel> hope you can convince me that I'm wrong! What do you think? > > In Ada 95 an exception can carry a message (String), I believe this >functionality was added to help logging (an example of use you give). >Exceptions are not "scalar" types, look at Ada.Exceptions if you're >interested in Exception_Occurence objects. > > If you need more information to pass with an exception, may be it's >better to add a few parameters to your interface. > >-- >Laurent Guerby <guerby@gnat.com>, Team Ada. > "Use the Source, Luke. The Source will be with you, always (GPL)." Please allow me to expand on the notion of "adding a few parameters to your interface." It is a technique that I have found very useful. Where I work there are several radars with unique data interfaces (which are programmed in assembly language) that send data to a FORTRAN program that gathers data packets from many radars and puts them in a large block, sends this block to another computer (programmed in C) that broadcasts modified data blocks to my display program (written in Ada 83). There is no built-in error checking done by the assemblers, FORTRAN, or C compilers, and precious little error checking explictily done by those programmers. Consequently, my program received a lot of bad data during the initial integration phase. Since I had taken the trouble to define special types for the data packets and blocks of data packets (rather than just treating them as arrays of integers, like the assembly language, FORTRAN, and C programs did), the Ada compiler did some automatic checking for me, and immediately found errors in the data that had gone undetected for years by the previous display program. (The previous program, written in assembly language, just displayed incorrect positions and nobody realized it.) The automatic error detection was done in the RAW_DATA_PACKET package (which was responsible for converting the arrays of integers into records of the proper type). It raised an exception called RAW_DATA_PACKET.BAD_PACKET whenever it found a bad packet. As has been pointed out, Ada 83 exceptions have no parameters. That isn't really a problem. I simply save the current data block and the current value of the index before trying to decode each packet in the block. I included functions that return the current data block and the current index in package specification of RAW_DATA_PACKET. I programmed the display software so that whenever BAD_PACKET is raised, the exception handler calls these two functions to get the bad block and the pointer to the offending value. It displays an alarm on the screen, and writes the bad block (in hexadecimal ASCII) to a text file, with ">>>" pointing to the bad value. The upstream programs have fixed their problems, so I don't see this exception very often any more. (It does usually pop up the first time somebody tries to integrate a new radar with our test range, however.) But when it used to happen regularly, it gave us all the information we needed to instantly diagnose the problem. The moral of the story is that the exception is simply a flag that tells you something has gone wrong. If you take care to save the pertinent values before the exception is raised, and if you include a mechanism to retrieve those values when an exception has been detected, you have all the information you need. Do-While Jones -- +--------------------------------+ | Know Ada | | [Ada's Portrait] | | Will Travel | | wire do_while@ridgecrest.ca.us | +--------------------------------+ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: question on exceptions 1996-11-04 0:00 ` Do-While Jones @ 1996-11-06 0:00 ` Robert A Duff 1996-11-07 0:00 ` Tucker Taft 1996-11-08 0:00 ` Robert Dewar 0 siblings, 2 replies; 11+ messages in thread From: Robert A Duff @ 1996-11-06 0:00 UTC (permalink / raw) In article <55l00n$alv@ash.ridgecrest.ca.us>, Do-While Jones <do_while@lo-pan.ridgecrest.ca.us> wrote: >The moral of the story is that the exception is simply a flag that tells >you something has gone wrong. If you take care to save the pertinent >values before the exception is raised, and if you include a mechanism to >retrieve those values when an exception has been detected, you have all >the information you need. In a multi-tasking program, you would probably want to store this information in a task attribute. I still think that some other languages do it better (more type safety) than Ada. What I want is to declare what sort of information is attached to a particular exception name. Then the handler knows what type of information is attached, and references to this information can be type checked. C++, Java, CLOS, etc have this capability. While your solution works, it isn't quite as safe. For example, a handler for X might try to grab information that is only associated with exception Y. Or somebody might evilly call the function to get the extra information when not in an exception handler at all, when the information isn't available. Or an exception handler might call a procedure that internally raises-then-handles an exception, thus overwriting the information -- you have to be careful to grab the information before doing anything else in the exception handler that might invalidate the information. You could write the information-getting function to detect these errors at run time, but it would be slightly nicer to have compile-time error detection. You can write comments in the code explaining the proper use of this function, but it would be slightly nicer to have that information encoded in the program itself, in a standard way. By the way, during the design of Ada 9X, it was suggested that we have functions for querying things like the Current_Exception_Name and Current_Exception_String. However, the design team rejected this idea for the reasons explained above -- presumably the semantics of calling these at the wrong time would be "erroneous", which is bad. My main complaint about the Ada 95 design for this stuff is that the information associated with an exception *must* be of type String. I suppose you can encode whatever information you want in a string, but not with type safety. - Bob ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: question on exceptions 1996-11-06 0:00 ` Robert A Duff @ 1996-11-07 0:00 ` Tucker Taft 1996-11-08 0:00 ` Robert A Duff 1996-11-08 0:00 ` Robert Dewar 1 sibling, 1 reply; 11+ messages in thread From: Tucker Taft @ 1996-11-07 0:00 UTC (permalink / raw) Robert A Duff (bobduff@world.std.com) wrote: : ... My main : complaint about the Ada 95 design for this stuff is that the information : associated with an exception *must* be of type String. I suppose you : can encode whatever information you want in a string, but not with type : safety. Perhaps Bob and I have different memories of this issue. An Ada 95 exception occurrence can conceptually carry any information of any type. The only kind of information for which we specified a standard set of operations was type String, largely because in a "when others" clause, String is about all you could usefully presume. On the other hand, there is nothing precluding an implementor, or the implementor "community," from defining additional packages for allowing additional kinds of information to be carried along with an exception occurrence. In particular, such a package might define a root tagged type for carrying information (e.g. type Root_Exception_Info is tagged private;) which in the root type only carries one string, but then allow a user to extend this type to carry any other kind of information. In an exception handler, membership tests could be used to determine what sort of additional information was passed along. Personally, I had always envisioned that these new packages would appear over time, but perhaps we should have given more of a push for them in the Ada 95 RM. : - Bob -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: question on exceptions 1996-11-07 0:00 ` Tucker Taft @ 1996-11-08 0:00 ` Robert A Duff 0 siblings, 0 replies; 11+ messages in thread From: Robert A Duff @ 1996-11-08 0:00 UTC (permalink / raw) In article <E0I7zK.E4x.0.-s@inmet.camb.inmet.com>, Tucker Taft <stt@houdini.camb.inmet.com> wrote: >In an exception handler, membership tests could be used to determine >what sort of additional information was passed along. Yeah, I also envisioned such implementation-defined stuff. But I want to declare the type of the attached information at the point of the exception declaration, so that *handlers* can know for sure (at compile time) that every *raise* of, say, The_Sky_Is_Falling will attach (say) the current color of the sky. The membership test isn't so awful, with appropriate comments at the point of the exception declaration, but it *could* be done at compile time. - Bob ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: question on exceptions 1996-11-06 0:00 ` Robert A Duff 1996-11-07 0:00 ` Tucker Taft @ 1996-11-08 0:00 ` Robert Dewar 1996-11-09 0:00 ` Tucker Taft 1 sibling, 1 reply; 11+ messages in thread From: Robert Dewar @ 1996-11-08 0:00 UTC (permalink / raw) Bob Duff says "By the way, during the design of Ada 9X, it was suggested that we have functions for querying things like the Current_Exception_Name and Current_Exception_String. However, the design team rejected this idea for the reasons explained above -- presumably the semantics of calling these at the wrong time would be "erroneous", which is bad. My main complaint about the Ada 95 design for this stuff is that the information associated with an exception *must* be of type String. I suppose you can encode whatever information you want in a string, but not with type safety." I see no reason why these could not be functoins which can only be called within a handler, checked statically by the compiler. This is how GNAT implements the DEC Current_Exception package (which has these semantics). ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: question on exceptions 1996-11-08 0:00 ` Robert Dewar @ 1996-11-09 0:00 ` Tucker Taft [not found] ` <E0Mr58.D00@world.std.com> 0 siblings, 1 reply; 11+ messages in thread From: Tucker Taft @ 1996-11-09 0:00 UTC (permalink / raw) Robert Dewar (dewar@merv.cs.nyu.edu) wrote: : Bob Duff says :> "By the way, during the design of Ada 9X, it was suggested that we have :> functions for querying things like the Current_Exception_Name and :> Current_Exception_String. However, the design team rejected this idea :> for the reasons explained above -- presumably the semantics of calling :> these at the wrong time would be "erroneous", which is bad. : I see no reason why these could not be functoins which can only be called : within a handler, checked statically by the compiler. This is how GNAT : implements the DEC Current_Exception package (which has these semantics). There would still be some possible ambiguities associated with such functions. What are their semantics when there is an exception raised and then handled in some statement within the handler, but preceding the call to one of these special functions? Does it report the most recent exception raised, or does it report the exception being handled by the current handler? Also, what happens if you rename such a subprogram? Does the renaming retain its special status? I presume we generally agree that having a namable exception occurrence object makes the semantics clearer, and gives the programmer a bit more flexibility. -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <E0Mr58.D00@world.std.com>]
* Re: question on exceptions [not found] ` <E0Mr58.D00@world.std.com> @ 1996-11-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 11+ messages in thread From: Robert Dewar @ 1996-11-09 0:00 UTC (permalink / raw) Bob Duff says "Think about implementation difficulty. One reason people advocated a "plain old function" was to make it easy to implement. But if that function has special rules, then the compiler has to special-case it anyway, so it's probably even *harder* to implement it." Absolutely! Implementing the DEC package Current_Exception which is, on the face of it, a collection of "plain old fujnctions", is a major pain, and the front end of the compiler has to know all sorts of special things about the functions in this package. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: question on exceptions 1996-11-02 0:00 question on exceptions Michiel Perdeck 1996-11-03 0:00 ` Robert A Duff 1996-11-03 0:00 ` Laurent Guerby @ 1996-11-04 0:00 ` Michel Gauthier 2 siblings, 0 replies; 11+ messages in thread From: Michel Gauthier @ 1996-11-04 0:00 UTC (permalink / raw) In article <E090uD.Kx6@tip.nl>, michiel.perdeck@cmg.nl wrote: >> [...] >> >> Questions: >> Unlike an exception in C++, an Ada exception cannot carry any >> extra information besides it's own name. [...] Ada _can_ do this : - directly, in the case of String values, - indirectly, for every type with functions similar to the Image and Value attributes. Attaching a String to a raise is a basic operation available in the Ada.Exceptions predefined package. For things other than String values, you can attach the Image of what you want to attach. Inside the exception handler, you can extract the message, and take its Value, which gets back the initial value. Caution : this works only if you can control that all raises are correctly attached. Therefore, either you restrict such uses to non-resusable parts, or you handle Constraint_Error possibly caused by the back-parsing of the message. ---------- ---------- ---------- ---------- Michel Gauthier / Laboratoire d'informatique 123 avenue Albert Thomas / F-87060 Limoges telephone + 33 () 05 55 45 73 35 [or ~ 72 32] fax +33 () 05 55 45 73 15 [or ~72 01] no initial zero from abroad ! ! ! ---------- ---------- ---------- ---------- Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9 If you feel year 2000 a stupid mystic craze, use numeration base 9 ---------- ---------- ---------- ---------- ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~1996-11-09 0:00 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-11-02 0:00 question on exceptions Michiel Perdeck 1996-11-03 0:00 ` Robert A Duff 1996-11-03 0:00 ` Laurent Guerby 1996-11-04 0:00 ` Do-While Jones 1996-11-06 0:00 ` Robert A Duff 1996-11-07 0:00 ` Tucker Taft 1996-11-08 0:00 ` Robert A Duff 1996-11-08 0:00 ` Robert Dewar 1996-11-09 0:00 ` Tucker Taft [not found] ` <E0Mr58.D00@world.std.com> 1996-11-09 0:00 ` Robert Dewar 1996-11-04 0:00 ` Michel Gauthier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox