* Re: Help Me Please :)
2000-03-27 0:00 ` Robert A Duff
@ 2000-03-27 0:00 ` Hyman Rosen
2000-03-28 0:00 ` Robert Dewar
` (4 subsequent siblings)
5 siblings, 0 replies; 39+ messages in thread
From: Hyman Rosen @ 2000-03-27 0:00 UTC (permalink / raw)
Robert A Duff <bobduff@world.std.com> writes:
> The "raises set" of a procedure defines what exceptions it can raise.
> The problem is that this rule is checked at run time. Java is closer to
> the right solution -- it checks that rule at compile time. However,
> Java suffers from the "cry wolf" problem. I think it's possible to
> avoid the "cry wolf" problem, and still do most of that checking at
> compile time.
Most people on comp.lang.c++.moderated have concluded that C++ throw
specifications are useless, except for the throw() spec which says
that a function will throw no exceptions at all. It would be interesting
to see a design which works well.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-27 0:00 ` Robert A Duff
2000-03-27 0:00 ` Hyman Rosen
@ 2000-03-28 0:00 ` Robert Dewar
2000-03-30 0:00 ` Mats Weber
2000-03-28 0:00 ` reason67
` (3 subsequent siblings)
5 siblings, 1 reply; 39+ messages in thread
From: Robert Dewar @ 2000-03-28 0:00 UTC (permalink / raw)
In article <wccya74m18e.fsf@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
> There's no hierarchy of exceptions.
I dislike complexification of exception handling. Many Ada
programmers greatly overuse exceptions, and in particular
define far too many separate exceptions. When it comes to
exception handling, the rule should be keep it very simple.
> (On the other hand, Ada *pretends* that it's OK to raise and
> handle Constraint_Error, but if you read RM-11.6, you'll find
> that's not quite true -- and I doubt if any Ada programmer
> other than Tucker Taft actually *understands* 11.6. So in
> practise, 11.6 says, "Do not handle predefined exceptions.")
Now now, that's completely disconnected from the real world :-)
"In practice", 11.6 says nothing of the sort at all.
It is often useful to be able to handle constraint error.
For example here is the implementation of one of the plus
operators in Calendar in GNAT:
function "+" (Left : Time; Right : Duration) return Time is
pragma Unsuppress (Overflow_Check);
begin
return (Left + Time (Right));
exception
when Constraint_Error =>
raise Time_Error;
end "+";
If you don't understand 11.6, at least don't make claims about
it that are excessive :-) Sure, the formulation of 11.6 is
complex, but you have to approach this with a pragmatist's hat
on, not a theoretician's viewpoint.
In practice many many Ada 95 programs have CE handlers and are
in practice perfectly portable. Even if in some cases a
theoretician could prove that it was possible to have an
implementation of Ada 95 that conformed to the RM under
which the handler is "wrong", that is irrelevant if no such
implementations exist or are likely to exist. In other cases,
even the theoretician's will not find any fault with the CE
handler :-)
Yes, Bob, I know you like to have the hope that the Ada RM is
a formal definition which precisely defines what you can and
cannot do. It is nowhere near that for many reasons, and a
pragmatic viewpoint always has to be in effect.
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-27 0:00 ` Robert A Duff
2000-03-27 0:00 ` Hyman Rosen
2000-03-28 0:00 ` Robert Dewar
@ 2000-03-28 0:00 ` reason67
2000-03-28 0:00 ` Robert Dewar
2000-03-29 0:00 ` Richard D Riehle
` (2 subsequent siblings)
5 siblings, 1 reply; 39+ messages in thread
From: reason67 @ 2000-03-28 0:00 UTC (permalink / raw)
In article <wccya74m18e.fsf@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
> (On the other hand, Ada *pretends* that it's OK to raise and handle
> Constraint_Error, but if you read RM-11.6, you'll find that's not
quite
> true -- and I doubt if any Ada programmer other than Tucker Taft
> actually *understands* 11.6. So in practise, 11.6 says, "Do not handle
> predefined exceptions.")
"Ladies and Gentlemen, Thank you for flying on the Boeing 777 Flight
633. Unfortunately, due to a minor bug in the flight control software
raising a predefined exception and Ada RM section 11.6, the flight
control software has crashed. We are now heading towards the ground at
700 miles per hour. Estimated time of arrival 10 seconds. Have a nice
day."
---
Jeffrey S. Blatt
"If the truth will kill them, let them die."
-- Immanuel Kant
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-28 0:00 ` reason67
@ 2000-03-28 0:00 ` Robert Dewar
2000-03-29 0:00 ` reason67
` (2 more replies)
0 siblings, 3 replies; 39+ messages in thread
From: Robert Dewar @ 2000-03-28 0:00 UTC (permalink / raw)
In article <8bqcu2$s0p$1@nnrp1.deja.com>,
reason67@my-deja.com wrote:
> In article <wccya74m18e.fsf@world.std.com>,
> Robert A Duff <bobduff@world.std.com> wrote:
>
> > (On the other hand, Ada *pretends* that it's OK to raise and
handle
> > Constraint_Error, but if you read RM-11.6, you'll find
that's not
> quite
> > true -- and I doubt if any Ada programmer other than Tucker
Taft
> > actually *understands* 11.6. So in practise, 11.6 says, "Do
not handle
> > predefined exceptions.")
>
> "Ladies and Gentlemen, Thank you for flying on the Boeing 777
Flight
> 633. Unfortunately, due to a minor bug in the flight control
software
> raising a predefined exception and Ada RM section 11.6, the
flight
> control software has crashed. We are now heading towards the
ground at
> 700 miles per hour. Estimated time of arrival 10 seconds. Have
a nice
> day."
Well there was no smiley there, so let's assume the (rather
hard to believe) point is being made seriously.
In that case it is way way off base. Any safety critical
software is validated and verified at the object level. You
never depend on the correctness of the compiler, or the
correctness of understanding of the high level language
semantics.
Furthermore, in most safety critical software, one would never
have such a handler? Why not because it might typically be the
case that the handler code is deactivated, and deactivated code
is not permitted in many SC protocols.
Finally, 11.6 is about optimization, it is almost always the
case that you want *no* optimization for SC code. Why? Because
you want the best possible correspondence between source code
and object code.
So in short, the scenario above is triply unlikely!
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-28 0:00 ` Robert Dewar
@ 2000-03-29 0:00 ` reason67
2000-03-29 0:00 ` Simon Wright
2000-04-06 0:00 ` Simon Pilgrim
2 siblings, 0 replies; 39+ messages in thread
From: reason67 @ 2000-03-29 0:00 UTC (permalink / raw)
In article <8brgcd$5kp$1@nnrp1.deja.com>,
Robert Dewar <robert_dewar@my-deja.com> wrote:
> Well there was no smiley there, so let's assume the (rather
> hard to believe) point is being made seriously.
>
> In that case it is way way off base. Any safety critical
> software is validated and verified at the object level. You
> never depend on the correctness of the compiler, or the
> correctness of understanding of the high level language
> semantics.
Not the point I was making and also not always the case. I have seen
safty critical systems that wrote their SRS's such that they did not
have to do V&V on the Object level. And they did not. I agree that they
should, but should and do are not always the same.
> Furthermore, in most safety critical software, one would never
> have such a handler? Why not because it might typically be the
> case that the handler code is deactivated, and deactivated code
> is not permitted in many SC protocols.
Since I have worked in Safty Critical software for 11 years with several
Aerospace Companies (I am a contract engineer), I can safely say that
while you may have reason to think that what you are saying is true, in
reality, it is not the way the code is delivered. In fact, one aircraft
that I worked on required that all exceptions be caught at the lowest
levels and propagated out of subprograms as status.
I expect you can quote more reasons why this is an incorrect way to do
Safty Critical software. I can state that your discription is inaccurate
for code I have seen and the code I have written for several aircraft
(military and otherwise).
Now where I have seen the kind of thing you are talking about is when
doing hard real-time embedded stuff (Greater that 256 MHz cycle time
with limited memory with no OS, but where I did that was in a simulator
which is definitely not safty critical).
> Finally, 11.6 is about optimization, it is almost always the
> case that you want *no* optimization for SC code. Why? Because
> you want the best possible correspondence between source code
> and object code.
That I agree with. The same is true with hard real-time (which on first
glace seems backwards).
---
Jeffrey S. Blatt
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-28 0:00 ` Robert Dewar
2000-03-29 0:00 ` reason67
@ 2000-03-29 0:00 ` Simon Wright
2000-04-06 0:00 ` Simon Pilgrim
2 siblings, 0 replies; 39+ messages in thread
From: Simon Wright @ 2000-03-29 0:00 UTC (permalink / raw)
Robert Dewar <robert_dewar@my-deja.com> writes:
> In that case it is way way off base. Any safety critical
> software is validated and verified at the object level. You
> never depend on the correctness of the compiler, or the
> correctness of understanding of the high level language
> semantics.
That may well be true of SIL4 software, but I believe not normally so
for SIL(n<4). In any case it all depends on the safety case and the
independent safety authority ..
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-28 0:00 ` Robert Dewar
2000-03-29 0:00 ` reason67
2000-03-29 0:00 ` Simon Wright
@ 2000-04-06 0:00 ` Simon Pilgrim
2000-04-07 0:00 ` Robert Dewar
2 siblings, 1 reply; 39+ messages in thread
From: Simon Pilgrim @ 2000-04-06 0:00 UTC (permalink / raw)
Robert Dewar wrote:
>
> In article <8bqcu2$s0p$1@nnrp1.deja.com>,
> reason67@my-deja.com wrote:
> > "Ladies and Gentlemen, Thank you for flying on the Boeing 777
> Flight
> > 633. Unfortunately, due to a minor bug in the flight control
> software
> > raising a predefined exception and Ada RM section 11.6, the
> flight
> > control software has crashed. We are now heading towards the
> ground at
> > 700 miles per hour. Estimated time of arrival 10 seconds. Have
> a nice
> > day."
As one of the many engineers who have worked on the Boeing 777 Primary
Flight Computer, I'd like to respond to that.
> Well there was no smiley there, so let's assume the (rather
> hard to believe) point is being made seriously.
>
> In that case it is way way off base. Any safety critical
> software is validated and verified at the object level. You
> never depend on the correctness of the compiler, or the
> correctness of understanding of the high level language
> semantics.
Correct. The PFC code was module tested at object level.
> Furthermore, in most safety critical software, one would never
> have such a handler? Why not because it might typically be the
> case that the handler code is deactivated, and deactivated code
> is not permitted in many SC protocols.
Right again.
> Finally, 11.6 is about optimization, it is almost always the
> case that you want *no* optimization for SC code. Why? Because
> you want the best possible correspondence between source code
> and object code.
Not true for the PFC. We have a lot of code to squeeze into that frame.
> So in short, the scenario above is triply unlikely!
More than that. We have a triple redundant system, with three PFCs per
airplane. Within each PFC are three lanes each with a different type of
processor. The same source code is compiled to the three different
targets with three different compilers.
--
Regards,
Simon Pilgrim
Senior Systems Engineer
Avionic Systems Division
BAE SYSTEMS, Rochester, UK
Views expressed above are not necessarily shared by my employer.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-04-06 0:00 ` Simon Pilgrim
@ 2000-04-07 0:00 ` Robert Dewar
2000-04-10 0:00 ` r_c_chapman
0 siblings, 1 reply; 39+ messages in thread
From: Robert Dewar @ 2000-04-07 0:00 UTC (permalink / raw)
In article <38ECEB56.8FD7596E@gecm.com>,
Simon Pilgrim <simon.pilgrim@gecm.com> wrote:
> > Finally, 11.6 is about optimization, it is almost always the
> > case that you want *no* optimization for SC code. Why?
> > Because
> > you want the best possible correspondence between source
> > code and object code.
>
> Not true for the PFC. We have a lot of code to squeeze into
> that frame.
Well "no optimization" is a relative term here, none of the
compilers you used had particularly strong optimizers by
modern standards. Certainly none of them took full
advantage of 11.6, which was the specific point of
this discussion.
Actually when the safety-critical crowd asks for no
optimization, they are making the usual mistake of
specifying a solution to their problem, rather than
stating the problem.
The problem is to make the examination of the object code
as easy as possible.
Certain types of optimization assist in this goal. For example,
with gnat, we usually find that -O1 assembly code is far easier
to follow than -O0 code, simply because there is so much less
of it.
On the other hand, if you have really fierce optimization,
involving high level algorithm substitution, propagation
of information all around the place, including erroneous
situations, massive restructuring of code, etc, then the
resulting object code can become quite complex to read.
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-04-07 0:00 ` Robert Dewar
@ 2000-04-10 0:00 ` r_c_chapman
0 siblings, 0 replies; 39+ messages in thread
From: r_c_chapman @ 2000-04-10 0:00 UTC (permalink / raw)
> Certain types of optimization assist in this goal. For example,
> with gnat, we usually find that -O1 assembly code is far easier
> to follow than -O0 code, simply because there is so much less
> of it.
I concur - results from our paper in Ada Europe 99 confirm this.
Brief summary:
On the original SHOLIS project, we had SPARK83 targetting 68040,
and we found the optimizer made very little difference to run-time
and/or object-code understandability, but the Alsys compiler
has hand-written code selection which makes the "unoptimized" code
quite reasonable in those terms.
I ported SHOLIS to SPARK95, and used GNAT/68k to recompile.
At -O0, GNAT produces more code than Alsys, and it's actually
harder to understand, since there are so many redundant loads
and stored littered about the place. At -O1, the GNAT code
is far smaller and easier reading. This is no surprise, since
GCC's code selection is table-driven.
Interestingly, we did not do full-scale object-code verification
(OCV) on SHOLIS, owing to the long track-record and stability
of the Alsys compiler. (well..and the simplicity of SPARK...)
On more recent targets (e.g. PowerPC), it's really important
to have _some_ optimizations on (particularly decent
register allocation) since the difference between
a register, a cache hit, and a main-memory access is so
much more pronounced on these targets. We tried
running code from VADSCross/PowerPC with -O0 on another project -
the results were disappointing, so we reverted to the _default_
level of -O4 for that compiler, which proved fine (this was also
a SIL4 project.)
High-level optimization that perform large-scale reorganisation
of code are definitely a no-no, but I can live with local improvements.
Overall, I recommend you simply avoid having to do full-on
OCV - it's very hard work!
- Rod Chapman
Praxis Critical Systems
rod@praxis-cs.co.uk
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-27 0:00 ` Robert A Duff
` (2 preceding siblings ...)
2000-03-28 0:00 ` reason67
@ 2000-03-29 0:00 ` Richard D Riehle
2000-03-29 0:00 ` Robert Dewar
` (2 more replies)
2000-03-30 0:00 ` Tucker Taft
2000-03-30 0:00 ` Mats Weber
5 siblings, 3 replies; 39+ messages in thread
From: Richard D Riehle @ 2000-03-29 0:00 UTC (permalink / raw)
In article <wccya74m18e.fsf@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
>Mats Weber <matsw@mail.com> writes:
>
>> I think the designers of Modula-3 got it just right. You can have a look
>> at http://www.m3.org/
>
>I beg to differ, again. ;-)
>
>I see several problems with Modula-3's exception mechanism, some of
>which are shared by Ada. (My knowledge of the language comes from
>Harbison's book, "Modula-3". I've never written a Modula-3 program.)
I agree with you about the Modula-3 problems. Do not entirely agree with
you about Ada. There could be some benefits to the paramterized
exception, but these would be small and are already adequately covered
by the features of Ada.Exceptions. Dr. Dewar and I do not usually
agree on the benefits of the functions in Ada.Exceptions, but we do
agree that exceptions are overused in most applications.
>There's no hierarchy of exceptions. This means that the designer of
>some code that raises exceptions must decide on the granularity of
>exception handling; it would be better for the handler to make that
>decision. For example, one handler might want to handle all "I/O
>errors", whereas another handler might want to handle just "disk-full
>error". Making exceptions first-class objects (which they are not, in
>Ada and Modula-3) would solve this problem, at no cost in language
>complexity.
There would certainly be an increase in complexity in the creation
of hierarchical exceptions.
>An exception takes just one parameter. Why not two or three or however
>many I like? Again, making exceptions extensible object types would
>solve the problem.
And what would be the parameter type(s)? Are you suggesting an
exception defined with parameters in the same way one defines
subprograms? That would seem to increase complexity of both the
compiler design and the resulting applications. It is an increase
in complexity that seems unnecessary under any but the most unusual
circumstances.
>The behavior in the presense of "checked run-time errors" (things like
>divide by zero, arithmetic overflow, array index out of bounds) is not
>defined by the language. So an array index out of bounds might raise
>Array_Index_Error on one implementation, and Constraint_Error on another
>implementation, and simply stop the program dead in its tracks on a
>third implementation. I don't like that non-portability.
I agree it is useful to track such things. That is why I like the
addition of Exception_Occurrence to the language in Ada.Exceptions.
when Some_Nasty_Error : Constraint_Error =>
Error_Manager.Log(Ada.Exceptions.
Exception_Information(Some_Nasty_Error));
This is where Dr. Dewar and I differ. I see this feature as important
for applications such as command and control systems. He sees it, as
of our last discussion of the subject, as less important than I.
>(On the other hand, Ada *pretends* that it's OK to raise and handle
>Constraint_Error, but if you read RM-11.6, you'll find that's not quite
>true -- and I doubt if any Ada programmer other than Tucker Taft
>actually *understands* 11.6. So in practise, 11.6 says, "Do not handle
>predefined exceptions.")
ALRM 11.6 rarely presents a problem to the applications programmer. It
behaves according to a set of rules that has no deleterious effect on
the underlying application. It is, as I read it, as set of permissions,
not a license to destroy source code intent.
>The "raises set" of a procedure defines what exceptions it can raise.
>The problem is that this rule is checked at run time. Java is closer to
>the right solution -- it checks that rule at compile time. However,
>Java suffers from the "cry wolf" problem. I think it's possible to
>avoid the "cry wolf" problem, and still do most of that checking at
>compile time.
The entire C-family of languages, especially C++, is somewhat problematic
when examining exception handling. This is another of the "devil is in
the details" issues. I don't think Java exception handling measures
up in those circumstances that Ada does well. Ada is simpler to
understand and probably a little more efficient. Also, Java exception
handling seems to lead people to depend too much on exception handling
when they ought to be writing programs to check conditions instead. Ada
95 has added the 'Valid attribute for such checking and it can be used
nicely in circumstances where one might otherwise raise an exception.
I am reminded of C.A.R. Hoare's Turing Award Lecture in which he criticized
Ada for having exception as part of the language. Now every language
has some kind of exception handling. Ada looks downright conservative
when compared to more recent offerings for exception management.
>There is no re-raise statement (spelled "raise;" in Ada), so a "when
>others" handler (Ada spelling again) can't propagate the same exception.
>You can't raise the same exception occurrence, because the thing
>available in the handler is not the occurrence, but just its parameter,
>and then only if you named a particular exception.
A Reraise_Occurrence is included in Ada.Exceptions. It is not very
difficult to invoke this routine when one declares a limited type of
Exception_Occurrence and attaches it to some Exception_ID. In fact,
one may save an Exception_Occurrence and raise it again at some other
point in the program.
>Return and exit statements are defined in terms of raising a RETURN or
>EXIT exception. That seems kludgy to me, because exceptions are for
>cases where the target of the jump is determined dynamically, whereas
>return and exit are jumping to a statically-known place. So it's sort
>of overkill. In practical terms, it means that a "when others" will
>handle a RETURN or EXIT, and you can't re-raise it, so the return
>doesn't actually return, and the exit doesn't actually exit the loop.
As mentioned above, it is possible to save and Exception_Occurrence
and ReRaise it. As to return types, it is also useful to use a 'Base
value for certain return types and check those on return. Of course,
you know this feature better than I. You also understand the
excellent arguments against doing it this way.
>All exceptions must be declared at top level. This solves the
>kludginess of Ada, where they can be declared anywhere, but act *as if*
>they were declared at top level. But I think there are better solutions
>to that problem, based on the "procedure declares what exceptions it can
>raise" idea of Modula-3, Java, etc.
Agree that exceptions should be declared at a very high ("top") level.
This is done quite nicely using child library units where the top level
of a hierarchy is the declaration of the exceptions one will use
throughout that hierarchy. In this case, they are also in scope for
any clients.
>There's nothing like Eiffel's preconditions, postconditions, and
>invariants, which tie exceptions to the conditions that cause them. In
>Modula-3, you can say "this thing might raise Stack_Full", whereas in
>Eiffel you can say, "this thing will raise Stack_Full if Full(S) is
>True."
No argument with your ideas about Eiffel. I would like to have some
model for pre-, post-, and invariants in the next version of Ada. At
that time, it would be appropriate to revisit some of the capabilities
of exception handling.
That being said, as you know, most safety-critical software will avoid
exceptions entirely. Another reason why the new 'Valid attribute is
becoming useful.
>So, I think CLOS, Clu, and Eiffel (and to some small extent, C++) all
>have better ideas about exceptions than Modula-3 (or Ada).
Agree about Eiffel. Not sure about CLOS or Clu. Definitely disagree
about C++. The exception handling in C++ can only be described as scary.
Richard Riehle
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-29 0:00 ` Richard D Riehle
@ 2000-03-29 0:00 ` Robert Dewar
2000-03-31 0:00 ` Richard D Riehle
2000-03-30 0:00 ` Mats Weber
2000-04-06 0:00 ` Wes Groleau
2 siblings, 1 reply; 39+ messages in thread
From: Robert Dewar @ 2000-03-29 0:00 UTC (permalink / raw)
In article <8brm79$jm3$1@slb6.atl.mindspring.net>,
Richard D Riehle <laoXhai@ix.netcom.com> wrote:
> I agree it is useful to track such things. That is why I like
> the addition of Exception_Occurrence to the language in
> Ada.Exceptions.
>
> when Some_Nasty_Error : Constraint_Error =>
> Error_Manager.Log(Ada.Exceptions.
> Exception_Information(Some_Nasty_Error));
>
> This is where Dr. Dewar and I differ. I see this feature as
> important for applications such as command and control
> systems. He sees it, as of our last discussion of the
> subject, as less important than I.
Well I am not quite sure what the disagreement is, but let
me make a couple of comments on the above code.
It is highly implementation dependent, on some implementations
it may give a useful symbolic traceback, on another, no output
at all, and on a third, may generate a complete core dump. The
output is "implementation defined", which means you know
absolutely nothing about what the above code does from a
portable point of view.
On a given compiler it may do something useful to you, but you
have to examine any such logging code wrt the implementation
you are using, and adjust the code accordingly. But in practice
most Ada 83 implementations provided facilities like this in
any case (actually many Ada 83 implementations provided much
more extensive capabilities, and the Ada 95 facilities are not
sufficient, we have had to add quite a bit to GNAT here, see
for example, GNAT.Exceptions.
Also, you hope that compilers have extended capabilities like
dumping the results of an exception EVEN if there are dependent
tasks that prevent propagation. Or dump exceptions that
otherwise terminate tasks silently.
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-29 0:00 ` Robert Dewar
@ 2000-03-31 0:00 ` Richard D Riehle
2000-03-31 0:00 ` Jean-Pierre Rosen
0 siblings, 1 reply; 39+ messages in thread
From: Richard D Riehle @ 2000-03-31 0:00 UTC (permalink / raw)
In article <8brs96$ikp$1@nnrp1.deja.com>,
Robert Dewar <robert_dewar@my-deja.com> wrote:
>In article <8brm79$jm3$1@slb6.atl.mindspring.net>,
> Richard D Riehle <laoXhai@ix.netcom.com> wrote:
>> I agree it is useful to track such things. That is why I like
>> the addition of Exception_Occurrence to the language in
>> Ada.Exceptions.
>>
>> when Some_Nasty_Error : Constraint_Error =>
>> Error_Manager.Log(Ada.Exceptions.
>> Exception_Information(Some_Nasty_Error));
>>
>> This is where Dr. Dewar and I differ. I see this feature as
>> important for applications such as command and control
>> systems. He sees it, as of our last discussion of the
>> subject, as less important than I.
>
>Well I am not quite sure what the disagreement is, but let
>me make a couple of comments on the above code.
You and I have had a discussion about this and we see its value
for applications a little differently, as reflected in your
note, below.
>It is highly implementation dependent, on some implementations
>it may give a useful symbolic traceback, on another, no output
>at all, and on a third, may generate a complete core dump. The
>output is "implementation defined", which means you know
>absolutely nothing about what the above code does from a
>portable point of view.
It is certainly implementation dependent. It is also not very useful
for for what Joyce Tokar calls, "deeply embedded" software since we
do not want to be passing strings all over the place.
That being said, if Exceptions.Exception_Information does return
useful information for a given compiler when used in something such
as a command and control application, this could be a nice feature
of the implementation.
>On a given compiler it may do something useful to you, but you
>have to examine any such logging code wrt the implementation
>you are using, and adjust the code accordingly. But in practice
>most Ada 83 implementations provided facilities like this in
>any case (actually many Ada 83 implementations provided much
>more extensive capabilities, and the Ada 95 facilities are not
>sufficient, we have had to add quite a bit to GNAT here, see
>for example, GNAT.Exceptions.
Certainly one has the issue of implementation dependency. However,
I am not sure I like the idea of parameterizing the exception itself.
I do like the Ada 95 addition of, optionally, adding an exception
occurrence for certain exceptions. Also, we can provide a parameter
in the form of a message for given exceptions. That allows us to
call the Exception_Message function where this is deemed useful.
That feature is not implementation dependent since we raise the
exception with a clear message.
A when others becomes problematic. That is one place where the
exception occurrence becomes important. Of course we can either
Raise a new exception at the place of a _when others_ or label
it with an exception occurrence. In either case, we have preserved
the efficiency of the exception model while allowing some kind
of parameter or access to other useful information.
>Also, you hope that compilers have extended capabilities like
>dumping the results of an exception EVEN if there are dependent
>tasks that prevent propagation. Or dump exceptions that
>otherwise terminate tasks silently.
Well, yes, that would be nice. On the other hand, if we can target
our exception messages with message parameters, these can be quite
useful as part of the overall design. Also, the string message could
be designed to permit conversion to some other data type using the
features of Ada.Text_IO. This is up to the designer, but it does
imply a fairly high level of flexibility when one really needs this
sort of thing. In this case, there is no dependency on the underlying
implementation. We get the general capability of the parameterized
exception when we need it.
I think the Ada.Exceptions package is greatly underrated by a lot of
people. As mentioned above, it is not appropriate for every kind of
system, but is quite useful when one applies some creativity to its
usages.
Richard Riehle
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-31 0:00 ` Richard D Riehle
@ 2000-03-31 0:00 ` Jean-Pierre Rosen
2000-03-31 0:00 ` Pascal Obry
0 siblings, 1 reply; 39+ messages in thread
From: Jean-Pierre Rosen @ 2000-03-31 0:00 UTC (permalink / raw)
[long discussions about the value of parameterized exceptions snipped]
My 2 Euro-cents:
Exceptions are a programming tool, not a high level error-handling
mechanism.
In any project, you must define a policy for handling errors. Exceptions are
a powerful tool for unwinding the call stack, and without them, there are
many error handling policies that you could not define. They do NOT free you
from defining the policy for a project!
If you need to store more information when an error occurs, call some Error
procedure, and define it the way you like; there you can store the context
in a global variable, or if you need to make it tasking safe, in a task
attribute.
For those who can read french, there is a chapter in my book detailing these
issues (shameless plug: http://pro.wanadoo.fr/adalog/livrejpr.htm).
--
---------------------------------------------------------
J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-29 0:00 ` Richard D Riehle
2000-03-29 0:00 ` Robert Dewar
@ 2000-03-30 0:00 ` Mats Weber
2000-03-31 0:00 ` Richard D Riehle
2000-04-06 0:00 ` Wes Groleau
2 siblings, 1 reply; 39+ messages in thread
From: Mats Weber @ 2000-03-30 0:00 UTC (permalink / raw)
Richard D Riehle wrote:
> And what would be the parameter type(s)? Are you suggesting an
> exception defined with parameters in the same way one defines
> subprograms? That would seem to increase complexity of both the
> compiler design and the resulting applications. It is an increase
> in complexity that seems unnecessary under any but the most unusual
> circumstances.
I think the increase in complexity is already present in Ada.Exceptions.
Implementations have to reserve space for and pass that string around,
so I don't see why one could not pass other types.
I made a proposal for this in my thesis, you can have a look at it at:
http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html#RTFToC99
it's really not that complicated.
Without this mechanism, it is quite hard to interface systems like POSIX
in a clean way, where there is a single exception + an error code. With
parameterized exceptions, it is very easy.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-30 0:00 ` Mats Weber
@ 2000-03-31 0:00 ` Richard D Riehle
0 siblings, 0 replies; 39+ messages in thread
From: Richard D Riehle @ 2000-03-31 0:00 UTC (permalink / raw)
In article <38E389D7.5CD82114@mail.com>,
Mats Weber <matsw@mail.com> wrote:
>I think the increase in complexity is already present in Ada.Exceptions.
>Implementations have to reserve space for and pass that string around,
>so I don't see why one could not pass other types.
As I mentioned in my earlier reply to Robert Dewar, one can Raise
and exception with the procedure in Ada.Exceptions where the string
variable is nothing more than some numeric value(s) in string format.
Strings are rather portable across many different platforms. These
can be decomposed into their constituent numeric values and used for
communicating with various operating systems.
>Without this mechanism, it is quite hard to interface systems like POSIX
>in a clean way, where there is a single exception + an error code. With
>parameterized exceptions, it is very easy.
As mentioned above, the Ada.Exceptions.Raise_Exception procedure
allows us to link an exception identity to a message in the form
of a string and Ada.Text_IO allows us to convert that string into
an integer value for those exceptions where that might be appropriate.
This is not implementation dependent and provides the very capability
we are discussing.
Richard Riehle
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-29 0:00 ` Richard D Riehle
2000-03-29 0:00 ` Robert Dewar
2000-03-30 0:00 ` Mats Weber
@ 2000-04-06 0:00 ` Wes Groleau
2 siblings, 0 replies; 39+ messages in thread
From: Wes Groleau @ 2000-04-06 0:00 UTC (permalink / raw)
> when Some_Nasty_Error : Constraint_Error =>
> Error_Manager.Log(Ada.Exceptions.
> Exception_Information(Some_Nasty_Error));
>
> This is where Dr. Dewar and I differ. I see this feature as important
> for applications such as command and control systems. He sees it, as
> of our last discussion of the subject, as less important than I.
I see it as valuable for debugging when you have a million SLOC
you didn't write! Unfortunately, some compiler vendors do not
see its value and hence take advantage of the laxity of the RM
in that area.
--
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-27 0:00 ` Robert A Duff
` (3 preceding siblings ...)
2000-03-29 0:00 ` Richard D Riehle
@ 2000-03-30 0:00 ` Tucker Taft
2000-03-30 0:00 ` Mats Weber
5 siblings, 0 replies; 39+ messages in thread
From: Tucker Taft @ 2000-03-30 0:00 UTC (permalink / raw)
Robert A Duff wrote:
> ...
> (On the other hand, Ada *pretends* that it's OK to raise and handle
> Constraint_Error, but if you read RM-11.6, you'll find that's not quite
> true -- and I doubt if any Ada programmer other than Tucker Taft
> actually *understands* 11.6. So in practise, 11.6 says, "Do not handle
> predefined exceptions.")
This sounds like a request for a quick tutorial on 11.6 ;-).
Here is my nickel tour:
RM95 11.6(5) says, effectively, that you can remove dead code,
even if it might raise an exception due to failing a language-defined check.
RM95 11.6(6) says that the compiler (or hardware) can do
instruction scheduling (i.e. reordering) even
if there are language-defined checks among
the instructions, meaning that if you handle an exception raised
by the failure of a language-defined check, it might be "imprecise."
However, it won't be so imprecise as to disrupt some
separately compiled "abstraction" in the middle of an
operation, presuming the check failed outside of the abstraction.
Or for the one-cent summary: dead code removal and instruction
reordering can be performed without worrying too much
about language-defined checks, so long as you don't use
any "undefined" results (i.e., the result of an operation that failed
a language-defined check) and you don't screw up external
abstractions.
> ...
> - Bob
--
-Tucker Taft stt@averstar.com http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.) Burlington, MA USA
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Help Me Please :)
2000-03-27 0:00 ` Robert A Duff
` (4 preceding siblings ...)
2000-03-30 0:00 ` Tucker Taft
@ 2000-03-30 0:00 ` Mats Weber
5 siblings, 0 replies; 39+ messages in thread
From: Mats Weber @ 2000-03-30 0:00 UTC (permalink / raw)
Robert A Duff wrote:
>
> Mats Weber <matsw@mail.com> writes:
> > I think the designers of Modula-3 got it just right.
> I beg to differ, again. ;-)
I agree with you on most points. What I meant is that the idea of being
able to pass a parameter (even if only one) when raising an exception is
much better than Ada's current approach where the only thing you can
pass is a string.
This would have been a very simple change to the language (almost as
simple as including a string parameter in an exception occurence), and
the mechanism can be used to simulate a hierarchy of exceptions, using a
single exception with a tagged type as a paramter.
^ permalink raw reply [flat|nested] 39+ messages in thread