comp.lang.ada
 help / color / mirror / Atom feed
* Re: Propagation of unhandled exceptions during elaboration, in a tasking program
  1999-11-01  0:00 Propagation of unhandled exceptions during elaboration, in a tasking program David C. Hoos, Sr.
@ 1999-11-01  0:00 ` Robert Dewar
  1999-11-02  0:00 ` Nick Roberts
  1 sibling, 0 replies; 6+ messages in thread
From: Robert Dewar @ 1999-11-01  0:00 UTC (permalink / raw)


In article <7vjvb3$kn5$1@hobbes2.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> My question is this -- is the behavior I've described
> what is expected from an Ada program?


Yes.


Sent via Deja.com http://www.deja.com/
Before you buy.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Propagation of unhandled exceptions during elaboration, in a tasking program
@ 1999-11-01  0:00 David C. Hoos, Sr.
  1999-11-01  0:00 ` Robert Dewar
  1999-11-02  0:00 ` Nick Roberts
  0 siblings, 2 replies; 6+ messages in thread
From: David C. Hoos, Sr. @ 1999-11-01  0:00 UTC (permalink / raw)


Hi all,
I have a question about the expected behavior of an Ada
program when an unhandled exception is raised during
elaboration, and other tasks (at least threads) are running.

The context is this:

  I have a package called Configuration_Data that exports a
number of parameterless functions that return values used
in the declarations of various items -- e.g. the block_size
and block_count for storage pools, etc.  This package obtains
the values returned by these functions from a text file that
is opened and read during the elaboration of the package body.

An exception block surrounds the call to open the file, and
any exception is re-raised with added exception information:
e.g. "attempting to open file """ & Filename & """."

This scheme has worked well, giving the use an informative
error message if the configuration file cannot be opened.

However, in a tasking program, several threads have been
started by the time Configuration_Data is elaborated, and
the exception information is not written to the standard
output nor to the standard error file, if the file cannot
be opened.

I "worked around" the problem, by, instead of re-raising
the exception, writing the informative message to the
standard error file, and calling
POSIX.Process_Primitives.Exit_Process.  Now, the user
sees what's wrong, and knows what corrective action to take.



My question is this -- is the behavior I've described
what is expected from an Ada program?










^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Propagation of unhandled exceptions during elaboration, in a tasking  program
  1999-11-01  0:00 Propagation of unhandled exceptions during elaboration, in a tasking program David C. Hoos, Sr.
  1999-11-01  0:00 ` Robert Dewar
@ 1999-11-02  0:00 ` Nick Roberts
  1999-11-02  0:00   ` Robert Dewar
  1 sibling, 1 reply; 6+ messages in thread
From: Nick Roberts @ 1999-11-02  0:00 UTC (permalink / raw)


"David C. Hoos, Sr." wrote:
> 
> Hi all,
> I have a question about the expected behavior of an Ada
> program when an unhandled exception is raised during
> elaboration, and other tasks (at least threads) are running.
> ...
> My question is this -- is the behavior I've described
> what is expected from an Ada program?

It may be an indulgence on my part a little, but I'd like to see your
code (preferably with the irrelevant bits elided), and a more complete
description of what you expected to happen, and what actually happens.
Also, compiler and target, please!

-- 
Nick Roberts
Computer Consultant (UK)
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos






^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Propagation of unhandled exceptions during elaboration, in a tasking program
  1999-11-02  0:00 ` Nick Roberts
@ 1999-11-02  0:00   ` Robert Dewar
  1999-11-02  0:00     ` Robert A Duff
  0 siblings, 1 reply; 6+ messages in thread
From: Robert Dewar @ 1999-11-02  0:00 UTC (permalink / raw)


In article <381E44F2.CA734022@callnetuk.com>,
  Nick Roberts <nickroberts@callnetuk.com> wrote:
> It may be an indulgence on my part a little, but I'd like to
see your
> code (preferably with the irrelevant bits elided), and a more
complete
> description of what you expected to happen, and what actually
happens.
> Also, compiler and target, please!


Why the latter, this is most certainly not a target or
implementation specific issue, but just one of standard
Ada semantics (waiting for task termination).


Sent via Deja.com http://www.deja.com/
Before you buy.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Propagation of unhandled exceptions during elaboration, in a tasking program
  1999-11-02  0:00   ` Robert Dewar
@ 1999-11-02  0:00     ` Robert A Duff
  1999-11-02  0:00       ` Robert Dewar
  0 siblings, 1 reply; 6+ messages in thread
From: Robert A Duff @ 1999-11-02  0:00 UTC (permalink / raw)


Robert Dewar <robert_dewar@my-deja.com> writes:

> Why the latter, this is most certainly not a target or
> implementation specific issue, but just one of standard
> Ada semantics (waiting for task termination).

But the issue was whether an error message got printed, and I don't
think the RM has anything to say about that.  To me, it seems friendly
to print the message *before* doing any task waiting.  After all, the
program might well wait forever, since the main procedure never causes
some tasks to go ahead.  Of course, it's not sensible to print *any*
messages on many embedded systems.

Also, there's an obscure Implementation Permission in 10.2(30), which
*allows* the implementation to abort all the tasks in this situation.
I don't think any implementations actually do that.

- Bob




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Propagation of unhandled exceptions during elaboration, in a tasking program
  1999-11-02  0:00     ` Robert A Duff
@ 1999-11-02  0:00       ` Robert Dewar
  0 siblings, 0 replies; 6+ messages in thread
From: Robert Dewar @ 1999-11-02  0:00 UTC (permalink / raw)


In article <wcchfj4yg37.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Also, there's an obscure Implementation Permission in
> 10.2(30), which *allows* the implementation to abort all the
> tasks in this situation. I don't think any implementations
> actually do that.


Interesting, actually it seems a good idea to take advantage of
this. A pity it is not more extensive, and would also apply to
the nested case (Constraint_Error raised, no CE handler
anywhere, but you get stuck waiting for an inner task to
terminate), not to mention the silent task termination case.

I really don't see generating junk output from a program whose
formal semantics is well defined and which is not expected to
generate any output.

However, I suppose an option to fix all three problems in the
obvious way at the same time would make sense if it is not the
standard mode.


Sent via Deja.com http://www.deja.com/
Before you buy.




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~1999-11-02  0:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-11-01  0:00 Propagation of unhandled exceptions during elaboration, in a tasking program David C. Hoos, Sr.
1999-11-01  0:00 ` Robert Dewar
1999-11-02  0:00 ` Nick Roberts
1999-11-02  0:00   ` Robert Dewar
1999-11-02  0:00     ` Robert A Duff
1999-11-02  0:00       ` Robert Dewar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox