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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,743cbb1eadac54f3 X-Google-Attributes: gid103376,public From: do_while@lo-pan.ridgecrest.ca.us (Do-While Jones) Subject: Re: question on exceptions Date: 1996/11/04 Message-ID: <55l00n$alv@ash.ridgecrest.ca.us>#1/1 X-Deja-AN: 194784869 references: organization: RidgeNet - SLIP/PPP Internet, Ridgecrest, CA. (619) 371-3501 newsgroups: comp.lang.ada Date: 1996-11-04T00:00:00+00:00 List-Id: In article 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 , 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 | +--------------------------------+