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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Brian Drummond <brian@shapes.demon.co.uk>
Newsgroups: comp.lang.ada
Subject: Re: Re-write a file in Ada
Date: Tue, 19 Jan 2016 12:24:36 -0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <n7l9u3$p95$1@dont-email.me>
References: <77e47c8b-7dcc-4e86-8f89-1f348cdf08dd@googlegroups.com>
	<888e0bed-6d19-4ab6-84e7-67dd2f227407@googlegroups.com>
	<n70o0l$ecn$5@dont-email.me>
	<73c2bbe1-15fc-4c29-b500-fb0a637abd91@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 19 Jan 2016 12:24:36 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="da745e888d4a5182b5fda6212bbb0a63";
	logging-data="25893"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+eFNbZZzwamJ1SpUsBqbYwgQomweoD1O0="
User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508
 git://git.gnome.org/pan2)
Cancel-Lock: sha1:iXpBPmARNHz+E1zgHEwCwTH3BqY=
Xref: news.eternal-september.org comp.lang.ada:29161
Date: 2016-01-19T12:24:36+00:00
List-Id: <comp.lang.ada>

On Mon, 18 Jan 2016 07:05:55 -0800, gautier_niouzes wrote:

> Le lundi 11 janvier 2016 18:18:48 UTC+1, Brian Drummond a écrit :
> 
>> > raised ADA.IO_EXCEPTIONS.END_ERROR : a-tigeli.adb:96
>> 
>> In outline, when you see this sort of error, find the installation's
>> "Ada include directory" which contains the named file...
>> 
>> locate a-tigeli.adb
>> /usr/lib/gcc/x86_64-linux-gnu/4.9/rts-native/adainclude/a-tigeli.adb
...
>> Looks like we ran out of file somehow. From here on it's usually
>> straightforward.
> 
> Sure - but all that investigation effort brings nothing: the exception's
> name gives already this hint: the end of a file was reached. The fact
> that it raised somewhere in the run-time library is obvious and brings
> zero information for finding the bug: no indication is given about where
> the exception occurred in the program. 

Yes, that is true for End_Error specifically, (assuming you have already 
learned what "End_Error" means. Which may not be obvious to a beginner) 

Other exceptions - Constraint_Error, Storage_Error and so on have a much 
wider range of causes, then this process can be more helpful. I could 
have been clearer that I wanted to make a wider point.

For example, tracing "Constraint_Error" that way, once landed me in the 
Ada.Command_Line package, which made it immediately obvious I wasn't 
trapping command lines with missing arguments.

> It's a shame that GNAT doesn't
> switch on its trace-back by default, IMHO. The current setup is
> disturbing for beginners and cumbersome for people using GNAT for larger
> programs.

Agreed. Traceback would be very helpful. Because I can never remember 
how, I'll outline it here, partly in the hope of memorising it. From

https://gcc.gnu.org/onlinedocs/gnat_ugn/Non-Symbolic-Traceback.html#Non-
Symbolic-Traceback

To enable this feature you must use the `-E' gnatbind's option. 
(And compile with -g for debug information)
gnatmake -g main.adb -bargs -E

A similar point has been made for the "Ada compliant" checking flags, and 
while Gnat has been improved in this area, I think you still need to add 
some flags, giving

gnatmake -g -gnataoE -fstack-check main.adb -bargs -E

-- Brian