Re: Common Error/Exception Handler

Re: Common Error/Exception Handler

[Robert A Duff]

In article <4l8d5i$31g@news.sanders.lockheed.com>,
John Cupak  <jcupak@isd99.sanders.lockheed.com> wrote:
>Wouldn't it be possible with the Ada 95 exception mechanisms to create a
>package of standard exceptions and a common error message procedure,
>import/rename the exceptions where appropriate, and let the common error
>message procedure take care of the details? 

I suppose it's possible, but it doesn't seem desirable.  The abstraction
in question ought to define what sort of things are errors, and what
exceptions are therefore raised.  Clients can then decide how to handle
those errors.  Why do you think this information ought to be more
global?

- Bob

Common Error/Exception Handler

[John Cupak]

I have observed that non-Ada programmers tend to create a "constant" error
number header file or package, and then use that constant to write/display the
corresponding error message. Ada programmers, however, tend to use "packaged"
exceptions, raise the exception where/when appropriate, and "handle" the
exception in an exception handler.

Wouldn't it be possible with the Ada 95 exception mechanisms to create a
package of standard exceptions and a common error message procedure,
import/rename the exceptions where appropriate, and let the common error
message procedure take care of the details? 

Inquiring minds want to know!

-- 
John J. Cupak, Jr., CCP     Internet       : jcupak@isd99.sanders.lockheed.com
Lockheed Sanders, Inc.      Lockheed LAN   : jcupak@mailgw.sanders.lockheed.com
95 Canal Street/MER15-2403  Lockheed DECNet: NHQVAX::CUPAK 
Nashua, NH 03061-0868       Work Telephone : 603 885-2142 FAX: 603 885-1480

Re: Common Error/Exception Handler

[John Cupak]

I was thinking that a "global error/exception handler" package would be easier
to maintain, since *all* error definitions and messages would be in a single
place. 

Comments?
-- 
John J. Cupak, Jr., CCP     Internet       : jcupak@isd99.sanders.lockheed.com
Lockheed Sanders, Inc.      Lockheed LAN   : jcupak@mailgw.sanders.lockheed.com
95 Canal Street/MER15-2403  Lockheed DECNet: NHQVAX::CUPAK 
Nashua, NH 03061-0868       Work Telephone : 603 885-2142 FAX: 603 885-1480

Re: Common Error/Exception Handler

[Laurent Guerby]

John Cupak:
: Wouldn't it be possible with the Ada 95 exception mechanisms to create a
: package of standard exceptions and a common error message procedure,
: import/rename the exceptions where appropriate, and let the common error
: message procedure take care of the details? 

Robert A Duff wrote:
: I suppose it's possible, but it doesn't seem desirable.  The abstraction
: in question ought to define what sort of things are errors, and what
: exceptions are therefore raised.  Clients can then decide how to handle
: those errors.  Why do you think this information ought to be more
: global?

John Cupak wrote:
:I was thinking that a "global error/exception handler" package would be easier
: to maintain, since *all* error definitions and messages would be in a single
: place. 
: 
: Comments?

   I don't think  you (John) are  talking about exceptions in  general
(like Bob), but about exceptions that  get propagated to the main unit
and are "user" reported as a console message or in a log file.

   In this  last case, a global  mechanism is desirable and  simple to
implement in Ada 95 as a global  error reporting package using new Ada
(95) features in this area.

   You should have a look at RM95-A.13, and see that in Ada 95, all IO
exceptions are  defined in a   single package, Ada.IO_Exceptions,  and
renamed when needed   elsewhere ;-).  In Ada   95  a message  can   be
associated to an exception occurence, see RM95-11.4.1, Ada.Exceptions.
   
-- 
--  Laurent Guerby, student at Telecom Bretagne (France), Team Ada.
--  "Use the Source, Luke. The Source will be with you, always (GPL)."
--  http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project).
--  Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat).

Re: Common Error/Exception Handler

[Michel Gauthier]

In article <4lggbm$fth@news.sanders.lockheed.com>, John Cupak
<jcupak@isd99.sanders.lockheed.com> wrote:

>>  I was thinking that a "global error/exception handler" package would
be easier
>>  to maintain, since *all* error definitions and messages would be in a single
>>  place. 
>>  
>>  Comments?

IMHO, this idea is not consistent with weak coupling principles _if_ your
package is unique for all the system.

At the opposite, I suggest to the students to group their exceptions in
a package that is common to all a "subsystem", say a library. This package
ought to be non-generic.

Yet better, if appropriate, this package with exceptions can sensibly be
the root of a hierarchy of components. 

In both cases, there are generally some other common entities which can
be declared together with the exceptions. Example :
 - Calendar declares exceptions, number of days and day names,
 - Calendar.Gregorian declares the types for years, months and days,
 - Calendar.Gregorian.Calendar declares the type Date itself.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
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
----------          ----------          ----------          ----------

Re: Common Error/Exception Handler

[Michel Gauthier]

In article <4l8d5i$31g@news.sanders.lockheed.com>, John Cupak
<jcupak@isd99.sanders.lockheed.com> wrote:

>>  I have observed that non-Ada programmers tend to create a "constant" error
>>  number header file or package, and then use that constant to
write/display the
>>  corresponding error message. Ada programmers, however, tend to use
"packaged"
>>  exceptions, raise the exception where/when appropriate, and "handle" the
>>  exception in an exception handler.

I apologize for having answered to a reply before receiving the original
posting.

Ada programmers tend (sensibly?) to encapsulate. For exceptions, this takes
the form that you evoke. The underlying concept is reporting, and both cases
are possible implementations, among others.

>>  Wouldn't it be possible with the Ada 95 exception mechanisms to create a
>>  package of standard exceptions and a common error message procedure,
>>  import/rename the exceptions where appropriate, and let the common error
>>  message procedure take care of the details? 

I guess it useful to insist on my first reply : the predefined package
Ada.Exceptions provides all the features you wish, or features that
permits building what you wish. Fortunately, the mechanism is flexible 
enough for people who would prefer other uses of exceptions. 

For additional information, see my
paper in Ada Letters about Ada95 exceptions.

FUNDAMENTAL QUESTION : is tracing of exceptions really useful ?

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
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
----------          ----------          ----------          ----------

Re: Common Error/Exception Handler

[tmoran]

In <gauthier-2404961547320001@164.81.60.62> Michel Gauthier asked:
>FUNDAMENTAL QUESTION : is tracing of exceptions really useful ?
If by tracing you mean a stack trace of what called what where,
my answer is YES.

Re: Common Error/Exception Handler

[LJMetzger]

On 24 Apr 1996 14:51:25 GMT 
gauthier@unilim.fr (Michel Gauthier) wrote:
>FUNDAMENTAL QUESTION : 
>is tracing of exceptions really useful ?

IMHO, it is a valuable tool used to reduce the 
"mean time to diagnose" an unwanted feature.
--

Lewis Metzger          LJMetzger@aol.com
Fair Lawn, NJ

Re: Common Error/Exception Handler

[Theodore E. Dennison]

LJMetzger wrote:
> 
> On 24 Apr 1996 14:51:25 GMT
> gauthier@unilim.fr (Michel Gauthier) wrote:
> >FUNDAMENTAL QUESTION :
> >is tracing of exceptions really useful ?
> 
> IMHO, it is a valuable tool used to reduce the
> "mean time to diagnose" an unwanted feature.

The VAX/Ada compiler had a feature where any fatal runtime error 
produced a full stack dump, including code block labels and line 
numbers, if run under the debugger. (This "feature" may have actually
been a DEC debugger script. Anyway,...)

I know of at least one major (NASA-sponsored) project that considered
this feature so vital, that all of the delivered code (including
real-time stuff) was to be run under the DEC debugger. They had (have)
very stringent yearly downtime limits written into the contract, so it
was considered vital to be able to track down any problems as quickly
as possible.

To be honest, I'm suprised more compilers or linkers don't offer an
option to produce a stack dump (although core dumps can be pretty 
useful too).
-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Common Error/Exception Handler

[John English]

Theodore E. Dennison (dennison@escmail.orl.mmc.com) wrote:
: The VAX/Ada compiler had a feature where any fatal runtime error 
: produced a full stack dump, including code block labels and line 
: numbers, if run under the debugger. (This "feature" may have actually
: been a DEC debugger script. Anyway,...)
: [...snip...]
: To be honest, I'm suprised more compilers or linkers don't offer an
: option to produce a stack dump (although core dumps can be pretty 
: useful too).

One of the things that really annoys me about GNAT is the ubiquitous
"raised unhandled exception" message.  A bit more detail (exception
name as a minimum, file name & source line number preferably) would
make life *sooo* much easier...

-- 
----------------------------------------------------------------------------
John English <je@brighton.ac.uk>, Dept. of Computing, University of Brighton
  "Disks are divided into sex and tractors..."
----------------------------------------------------------------------------

Re: Common Error/Exception Handler

[Jon S Anthony]

In article <Dr30w9.K0z@bton.ac.uk> je@bton.ac.uk (John English) writes:

> One of the things that really annoys me about GNAT is the ubiquitous
> "raised unhandled exception" message.  A bit more detail (exception
> name as a minimum, file name & source line number preferably) would
> make life *sooo* much easier...

That has been available since around 3.01 (I think).  It certainly
is there in 3.03 and 3.04.

For example,

rocedure Exception_Stuff is
 
    My_Exception : exception;
 
begin
    raise My_Exception;
end;
$ gnatmake exception_stuff.adb
$ exception_stuff
 
raised EXCEPTION_STUFF.MY_EXCEPTION
$

It also works for the "raise" operations in Ada.Exceptions where
you can attach an additional user specified message.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Common Error/Exception Handler

[Theodore E. Dennison]

John English wrote:
> 
> Theodore E. Dennison (dennison@escmail.orl.mmc.com) wrote:
> : To be honest, I'm suprised more compilers or linkers don't offer an
> : option to produce a stack dump (although core dumps can be pretty
> : useful too).
> 
> One of the things that really annoys me about GNAT is the ubiquitous
> "raised unhandled exception" message.  A bit more detail (exception
> name as a minimum, file name & source line number preferably) would
> make life *sooo* much easier...

I'll allow the annoyance, but don't single out GNAT. It truly annoys
me that I have to methodically add the following chunk of code to the
outer body of EVERY task and main routine I ever write under any VADS
compiler:

   exception
      when others =>
         V_I_Except.Exception_Current (ID => Exception_ID, PC => Exception_PC);
         
         Text_IO.Put_Line (Time_Stamp & ":" & Unit_Name & " terminating due to");
         Text_IO.Put_Line ("unhandled exception " & 
            V_I_Except.Exception_Name (Exception_ID) & " raised at PC " &
            Unsigned_Types.Unsigned_Integer'Image
               (To_Unsigned_Integer(Exception_PC))
            );

      raise;

If I have to write this same chunk of code ONE MORE TIME I think I'll add it to the
emacs-ada bindings!!! (Its more constructive than simply puking).

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Common Error/Exception Handler

[John English]

Jon S Anthony (jsa@organon.com) wrote:
: In article <Dr30w9.K0z@bton.ac.uk> je@bton.ac.uk (John English) writes:
: > One of the things that really annoys me about GNAT is the ubiquitous
: > "raised unhandled exception" message.  A bit more detail (exception
: > name as a minimum, file name & source line number preferably) would
: > make life *sooo* much easier...

: That has been available since around 3.01 (I think).  It certainly
: is there in 3.03 and 3.04.

Hmm, I'm starting to confuse myself with versions.  I'm running 3.03
under Linux and 3.01 under NT at home, 3.01 and 3.03 on the Suns and
Alphas at work, and 2.07 on the PCs in our student labs.  Since it's
usually students who come to see me with unhandled exception problems
(*I* never get into these pickles... :-) that would explain it.  So,
oops, I stand corrected.  And hopefully in some future version the
file name and line number will be provided too...

-- 
----------------------------------------------------------------------------
John English <je@brighton.ac.uk>, Dept. of Computing, University of Brighton
  "Disks are divided into sex and tractors..."
----------------------------------------------------------------------------

Re: Common Error/Exception Handler

[Robert A Duff]

In article <Dr6x9B.5LA@bton.ac.uk>, John English <je@bton.ac.uk> wrote:
>Hmm, I'm starting to confuse myself with versions.  I'm running 3.03
>under Linux and 3.01 under NT at home, 3.01 and 3.03 on the Suns and
>Alphas at work, and 2.07 on the PCs in our student labs.  Since it's
>usually students who come to see me with unhandled exception problems
>(*I* never get into these pickles... :-) that would explain it.  So,
>oops, I stand corrected.  And hopefully in some future version the
>file name and line number will be provided too...

To really get any useful information, you have to go into gdb.  File
name and line number are nice, but you *really* want a stack trace-back.

I'm not a big fan of hacking around in debuggers, but a stack trace-back
seems like a minimal amount of useful information.  For example, I
sometimes have a procedure called Validate(X), which raises an exception
if there's something wrong with X.  I don't just want to know where in
Validate it failed -- I want to know which call to Validate failed.

- Bob