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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.50.128.40 with SMTP id nl8mr3001022igb.4.1438261211244;
        Thu, 30 Jul 2015 06:00:11 -0700 (PDT)
X-Received: by 10.140.39.165 with SMTP id v34mr645988qgv.25.1438261211217;
 Thu, 30 Jul 2015 06:00:11 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!pg9no5328988igb.0!news-out.google.com!b31ni1340qge.0!nntp.google.com!z61no4169304qge.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 30 Jul 2015 06:00:11 -0700 (PDT)
In-Reply-To: <d1ufnpFt10rU1@mid.individual.net>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=81.203.145.32;
 posting-account=AFCLjAoAAABJAOf_HjgEEEi3ty-lG5m2
NNTP-Posting-Host: 81.203.145.32
References: <e610ca1e-4df6-4fbb-b3a1-ac35694d9072@googlegroups.com>
 <mp645u$abo$1@loke.gir.dk>
 <2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com>
 <mp8r8l$fnn$1@loke.gir.dk>
 <014427b1-ff7a-4a69-82e6-0330af77ed96@googlegroups.com>
 <mpbd8f$re$1@loke.gir.dk>
 <d5a73210-a67f-4d21-8b16-536af10ab157@googlegroups.com>
 <mpborl$6b9$1@dont-email.me>
 <91f88d79-197c-419f-84a8-908e05967a2c@googlegroups.com>
 <d1tst3FoastU1@mid.individual.net> <mpcjpo$93v$1@dont-email.me>
 <135c2b00-d13c-4f5d-a586-8aca442d363b@googlegroups.com>
 <mpcmqs$j0t$1@dont-email.me>
 <b68e14e7-e304-4220-81f5-67a88cef5767@googlegroups.com>
 <d1ufnpFt10rU1@mid.individual.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <947bb170-91aa-4e99-810e-7154be9bae6a@googlegroups.com>
Subject: Re: Running a preprocessor from GPS?
From: EGarrulo <egarrulo@gmail.com>
Injection-Date: Thu, 30 Jul 2015 13:00:11 +0000
Content-Type: text/plain; charset=ISO-8859-1
Xref: news.eternal-september.org comp.lang.ada:27203
Date: 2015-07-30T06:00:11-07:00
List-Id: <comp.lang.ada>

On Thursday, July 30, 2015 at 1:22:36 PM UTC+2, Niklas Holsti wrote:
> On 15-07-30 11:45 , EGarrulo wrote:
>  > Exceptions in Ada cannot ... be chained
> 
> I'm not sure what you mean by "chained", but an Ada exception handler 
> can either raise another exception, or re-raise the same exception, for 
> handling at higher levels.

By "chained", I mean that a failure in an operation can
cause a failure in the calling operation, and so on.  Let's
imagine that the initialization of an application relies
on reading a configuration file.  If the syntax of the 
configuration file is not correct, then the routine that
reads it will raise an exception, but this exception would
be too low-level to be meaningful for the user.  Therefore,
it makes sense to chain this exception to another higher-
level exception that explains what the application was
trying to do.  To the end user, this will appear as a chain
of exceptions:

- INITIALIZATION_ERROR: The application failed to initialize;
- CONFIGURATION_ERROR: The configuration failed;
- BAD_FORMAT: The configuration file isn't formatted correctly;
- SYNTAX_ERROR: The value of LEVEL is not of the expected type.

Basically, each exception in the chain answers the
question "why?"  Now, if you report only one of those
exceptions, then you lose context.  This is why you should
be able to chain exceptions.  Of course, you could achieve
a similar result by concatenating messages, but this way
you would be performing manually what the language should
have performed automatically.