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,2c0bee8a07770dd4
X-Google-Attributes: gid103376,public
From: Kevin Rigotti DRA <rigotti@atc.dra.hmg.gb>
Subject: Re: [Gnat] Finding exceptions without gdb
Date: 1996/11/07
Message-ID: <3281A927.48ED@atc.dra.hmg.gb>#1/1
X-Deja-AN: 195075742
references: <collins-0411960934280001@ratbert.cs.wm.edu>
 <32809C5B.6057@gsfc.nasa.gov>
content-type: text/plain; charset=us-ascii
organization: DRA ATC Systems Group/ NLR 'Narsim' team
mime-version: 1.0
newsgroups: comp.lang.ada
x-mailer: Mozilla 3.0Gold (X11; I; HP-UX A.09.05 9000/735)
Date: 1996-11-07T00:00:00+00:00
List-Id: <comp.lang.ada>


Stephen Leake wrote:

> Exceptions can be caught by breaking in the "__gnat_raise" routine and
> then doing a "bt" or "where" command.
If your code uses exceptions for non-fatal "error" handling, such
as 'file not found' when opening log files, then __gnat_raise gets
called rather too often to be useful.

If the exception is one you define yourself then it is worth wrapping
it in a procedure call. That way you can set a breakpoint on the
wrapper and get a stack back-trace, plus whatever diagnostics you
choose to put in the wrapper.

Just my $0.02

Kevin