Exceptions: Are they GOTOs?

Exceptions: Are they GOTOs?

[Bradley Edelman]

What do people think about exception handling?  I believe it to be a major
strength of Ada but there is a school of thought that exceptions are just
GOTO statements and should be avoided accordingly.

I think raising an exception is a neater way of handling an error than, say,
returning an error code or status.

I'd appreciate thoughts either way.

Thanks, Brad

Re: Exceptions: Are they GOTOs?

[Michel Gauthier]

In article <brad.837052481@ss1>, brad@cs.uwa.oz.au (Bradley Edelman) wrote:

>>  What do people think about exception handling?  I believe it to be a major
>>  strength of Ada but there is a school of thought that exceptions are just
>>  GOTO statements and should be avoided accordingly.
>>  
>>  I think raising an exception is a neater way of handling an error than, say,
>>  returning an error code or status.
>>  
>>  I'd appreciate thoughts either way.

You might find a somewhat long answer in my book
"Ada, a professional course", published by Macmillan.
May I abstract it here ?

The main difference between exception raise and goto is that :
- raising an exception is essentially declarative : I assert that...
- goto'ing (rather than 'going to') is imperative : do this...

Exceptions are not a concept. The concept is 'reporting' 
that the required service could not be obtained.
Exceptions can implement reports, as well as any kind
of status code. Most of the problems come from reporting,
not from its implementation.

The main problem is not in goto nor in raise but in the lable or 
in the handling. It is caused by the multipleness of program 
flows that converge. Hence :
- the assertion is a disjunct, therefore weakened,
- generally, the programmer has only a partial knowledge of
   this set of arrows, and in fact knows nothing useful.

Additional thougths later, if requested.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

Re: Exceptions: Are they GOTOs?

[Robert A Duff]

In article <brad.837052481@ss1>, Bradley Edelman <brad@cs.uwa.oz.au> wrote:
>What do people think about exception handling?  I believe it to be a major
>strength of Ada but there is a school of thought that exceptions are just
>GOTO statements and should be avoided accordingly.

Exceptions ARE like gotos -- only worse.  For a goto, you can know where
it's going by reading the code, and for a label, you can know how you're
going to get there by reading the code (assuming you don't have a LOT of
gotos going to the same label).  Furthermore, gotos are always local to
a given program unit.  Exceptions, on the other hand, are dynamic, so
you can't necessarily tell match "raise" with "handler" by reading the
code, and furthermore, they're much more global.

But that doesn't mean exception handlers are evil.  They're a powerful
(and therefore dangerous) tool, and should be used accordingly.

The school of thought you mention above is sort of silly, IMHO.  Some
people seem to use the word "goto" as a synonym for "evil", and avoid
actually *thinking* about if and when a goto, or a goto-like feature
such as exceptions, is appropriate.

Task swiching is vaguely like a goto, too, but that doesn't mean tasks
are evil.

>I think raising an exception is a neater way of handling an error than, say,
>returning an error code or status.

I strongly agree.

- Bob

P.S. The comments above are about Ada gotos.  There are languages where
you can goto a run-time-determined label value, and there are languages
where you can goto an outer procedure.  Raising an exception is
essentially the same thing as doing a goto to an outer scope, with the
label name (i.e. exception handler) being dynamically scoped.

Re: Exceptions: Are they GOTOs?

[steved]

In <brad.837052481@ss1>, brad@cs.uwa.oz.au (Bradley Edelman) writes:
>What do people think about exception handling?  I believe it to be a major
>strength of Ada but there is a school of thought that exceptions are just
>GOTO statements and should be avoided accordingly.
>
>I think raising an exception is a neater way of handling an error than, say,
>returning an error code or status.
>
>I'd appreciate thoughts either way.
>
>Thanks, Brad

In my experience I have seen programs that don't have exceptions that bomb
mysteriously when something goes wrong.  It is common practice in C to
call calloc and not check the result, just use the allocated memory (I expect
a flame for that, but I have seen this in "professional" programs).

On my current project, I implemented exception handlers in C using setjmp and
longjmp and encapsulate all "calloc's" within exception handlers.  This will
not keep the program from bombing, but at least I'll know why so I can fix the
problem.

I've read a lot of "rules" of programming: "goto's are bad", "avoid tasking
where possible".  But what I've learned by experience is that these "rules"
are really guidelines.  What's it's really all about is making code that may
be easily understood and therefore easily maintained (which is why Ada is
usually a better choice than 'C').

In trying to read code, if every possible error condition is checked in line
it may involve nested if's that are hard to read.  When exceptions are used
the checks can be made directly where the errors might occur within reusable
components, and the normal flow of code may look very simple.

My opinion:
When code is easier to read is safer and easier to maintain.
Exceptions can make code easier to read.
Therefore exceptions are not bad.

(Of course you can misuse exceptions like anything else)

Steve Doiel

Re: Exceptions: Are they GOTOs?

[Michael Feldman]

In article <4s4gic$etl@news.pacifier.com>,
Steve Doiel <steved@pacifier.com> wrote:

>In trying to read code, if every possible error condition is checked in line
>it may involve nested if's that are hard to read.  When exceptions are used
>the checks can be made directly where the errors might occur within reusable
>components, and the normal flow of code may look very simple.

Bingo.

Also keep in mind that in Ada, predefined and user-defined exceptions
are treated the same way. The _language_ defines the rules of
propagation for an unhandled exception - whether it is a predefined
or user-defined one. 

It is important to remember that these propagation rules serve as a
standard, well-defined, default flow of control. The programmer can
override the default by careful use of exception handlers, but unless
he chooses to suppress all checking, (s)he _cannot_ make the rules go
away. Constraint_Error (say) _will_ be propagated up the call chain 
until a handler is found.

So the question becomes "how can I best make use of this well-defined
capability, for my own abstractions"? There is simply _no_ knee-jerk
answer to the question - it is a design issue like all design issues.

There are many opinions. Here is mine.:-)
>
>My opinion:
>When code is easier to read is safer and easier to maintain.
>Exceptions can make code easier to read.
>Therefore exceptions are not bad.
>
>(Of course you can misuse exceptions like anything else)

[Gets on soapbox]

I get VERY weary of listening to those who try to stamp everything
GOOD or BAD. We have an absolutely outrageous tendency to do that,
in an industry where we pompously call ourselves "engineers".

[Steps down and gets back to exceptions]

1. By avoiding exceptions, one cheats oneself out of the ability to make
   a nice visual distinction between "normal" and "abnormal" flow of
   control. Furthermore, one simply cannot escape the propagation rules
   discussed above, so one might as well use them to advantage.

2. This leaves us with the problem of defining "normal". I said above
   that I was giving _opinion_ here, so your mileage may vary.:-)
   A few examples will sum it up.

   a. testing for the end of a file by handling Ada.Text_IO.End_Error
      is _inappropriate_. Why? Every sequential file has an end
      somewhere; it is NOT an error, or abnormal, to reach it. One
      should test for end-of-file with the predefined function
      Ada.Text_IO.End_Of_File.

      If I _forget_ to write correct code to test for end-of-file,
      and unexpectedly hit the end of the file, Ada.Text_IO.End_Error
      _will_ be raised. If that happens, it is because my code has a
      bug in it - I forgot the test (or wrote it incorrectly).

   b. Suppose we have an enumeration, say Days:

      TYPE Days IS (Mon, Tue, Wed, Thu, Fri, Sat, Sun);

      and given Today, we need to find Tomorrow. Suppose Today happens 
      to be Sun. If we are cycling through the week over and over, Mon 
      follows Sun _every week_; there is nothing abnormal about this. 
      Yet if we naively write

        Tomorrow := Days'Succ(Today);

      Constraint_Error will be raised when we "fall off the end of the
      type." So should we handle Constraint_Error, or just write a
      special case:

        IF Today = Days'Last THEN
          Tomorrow := Days'First;
        ELSE
          Tomorrow := Days'Succ(Today);
        END IF;

      Handling Constraint_Error here is _inappropriate_; I'd recommend
      the above IF instead.

   c. Suppose we have a stack package. Is it "abnormal" to try to pop
      an empty stack? In most cases, it is. The stack package should -
      by analogy with the End_Of_File situation in (a) - export _both_
      a Boolean function Is_Empty _and_ an exception Empty_Stack. Why?
      The package should give the client writer the opportunity to do the
      right thing (check the empty condition before popping), but provide
      well-defined "guaranteeable" behavior if the client blows it.

   d. Finally, what is the role of "status codes"? These are very useful
      anyway, to report various _normal_ results. Consider a table
      ("database") maintenance package, exporting the usual Insert,
      Search, Delete operations. Here, an OUT parameter like a
      Boolean flag Success is useful. Why?

      Is an unsuccessful search an error? Is it abnormal? Not in my
      opinion. When you look up a friend's number in the phone book,
      is it "abnormal" not to find it? No, it merely means your friend's
      number is unlisted. That is no error; it was quite deliberate.:-)

      The analogy to our table manager should be clear;  it is simply
      reporting a state, not a "normal" or "abnormal" condition.
      Indeed, it is the _client_ that must choose the next action.
      Should I add the item to the database? Or should I treat it
      as an error because it _should_ already have been there. That's
      part of the client design, not the package design.

      In my experience, this last area (d) is the most controversial, with
      the most variety in designs. There is no substitute for thinking
      through a consistent, common-sense design that provides the best
      chance of getting reliable and maintainable code. I can;t give
      a knee-jerk design here that will satisfy everyone. YMMV.:-)

Mike Feldman

Re: Exceptions: Are they GOTOs?

[Robert I. Eachus]

In article <4s8jjs$1gu@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:

     (Lots of good stuff including:)

   > If I _forget_ to write correct code to test for end-of-file,
   > and unexpectedly hit the end of the file, Ada.Text_IO.End_Error
   > _will_ be raised. If that happens, it is because my code has a
   > bug in it - I forgot the test (or wrote it incorrectly).

    However, I'd like to point out that always checking for
end-of-file is also inappropriate.  The rule I use is that an
incorrectly structured file can cause End_Error, but reaching the end
of the file "normally" should always be handled by checking for
end-of-file.

    For example, suppose I am reading a table of city names and high
and low temperatures for the day:

     while not Text_IO.End_of_File(foo) loop
       begin 
         Get_Name_of_City
         Int_IO.Get(foo, High);
         Int_IO.Get(foo, Low);
         Skip_Line(foo);
       exception
         when Text_IO.End_Error => 
           Deal_With_Incomplete_Record;
           exit;
         ...
       end;

     end loop;
     ...

   ...

   If I get to this handler it is because the file ended in an
incomplete record.  Now oyu may argue that I should read each line
into a buffer, then process it.  I will usually operate that way, but
the point still remains: you will get End_Error if temperature data is
missing, but correct files will never cause an exception.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Exceptions: Are they GOTOs?

[Michel Gauthier]

In article <19960718.083252.684@satcom.whit.org>, red@satcom.whit.org
(Robert Dunn) wrote:

>> [...]
>>  
>>  Second.  Can we kill this thread?  It is getting rather redundant.
>>  To answer the question as to exception=goto is simple.
>>  Does execution resume at the statement after the statement on which
>>  the exception occured (was raised)?  If it does, then exception<>goto.
>>  If it does not then exception=goto.

I wish to check if I understood correctly what you mean.

If we consider the 'end' or a subprogram or an 'end loop', then your condition
occurs. Hence, they are equal to gots's. Is that OK ? Similarly, 'then' is
a goto or not according to the value of the condition.

Where is there a funding for research on this topic ?

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

Re: Exceptions: Are they GOTOs?

[Robert Dunn]

In article <EACHUS.96Jul16140913@spectre.mitre.org>,
 on 16 Jul 1996 18:09:13 GMT,
 Robert I. Eachus <eachus@spectre.mitre.org> writes:
>
>					Robert I. Eachus
>
>with Standard_Disclaimer;
>use  Standard_Disclaimer;
>function Message (Text: in Clever_Ideas) return Better_Ideas is...

Hi,
Two things.  First, may I borrow this?

Second.  Can we kill this thread?  It is getting rather redundant.
To answer the question as to exception=goto is simple.
Does execution resume at the statement after the statement on which
the exception occured (was raised)?  If it does, then exception<>goto.
If it does not then exception=goto.

                Thanks, bye.

Re: Exceptions: Are they GOTOs?

[Robert Dewar]

Robert Dunn said

"Second.  Can we kill this thread?  It is getting rather redundant.
To answer the question as to exception=goto is simple.
Does execution resume at the statement after the statement on which
the exception occured (was raised)?  If it does, then exception<>goto.
If it does not then exception=goto."

A fascinating definition, by which if statements, while statements etc
are all gotos!

Robert, you are free to define things anyway you want, but if you want to
use a really bizarre and unusual definition like this (any change in flow
of control is a goto), then you sure need to make clear that you are using
this word very differently from anyone else.

Of course the issue of whether exceptions are gotos is very much a
definitional one, and is a rather silly way to frame a reasonable
question: namely are exceptions a useful and appropriate control
structure. And the answer to that is clearly yes -- there may not be
a complete consensus on this, but close to it I would think!

Re: Exceptions: Are they GOTOs?

[Larry J. Elmore]

On 18 Jul 1996, Robert Dewar wrote:

> Robert Dunn said
> 
> "Second.  Can we kill this thread?  It is getting rather redundant.
> To answer the question as to exception=goto is simple.
> Does execution resume at the statement after the statement on which
> the exception occured (was raised)?  If it does, then exception<>goto.
> If it does not then exception=goto."
> 
> A fascinating definition, by which if statements, while statements etc
> are all gotos!
> 
> Robert, you are free to define things anyway you want, but if you want to
> use a really bizarre and unusual definition like this (any change in flow
> of control is a goto), then you sure need to make clear that you are using
> this word very differently from anyone else.

Actually, I think Robert Dunn is right, technically. All the control 
statements are essentially a structured set of comparisons and gotos at 
the assembly language level, including exceptions. 

-- Larry J. Elmore, Sophomore, Computer Science, Montana State University    --
-- gle5989@trex2.oscs.montana.edu                                            --
-- "The said Constitution shall never be construed to authorize Congress to  --
--  prevent the people of the United States who are peaceable citizens from  --
--  keeping their own arms." -- Samuel Adams                                 --
-- "The great object is that every man be armed. Everyone who is able may    --
--  have a gun." -- Patrick Henry                                            --
-- Si vis pacem, para bellum.                                                --

Re: Exceptions: Are they GOTOs?

[Andy Askey]

"Larry J. Elmore" <GLE5989@trex2.oscs.montana.edu> wrote:


>Actually, I think Robert Dunn is right, technically. All the control 
>statements are essentially a structured set of comparisons and gotos at 
>the assembly language level, including exceptions. 

>-- Larry J. Elmore, Sophomore, Computer Science, Montana State University    --
>

Well, said.... I move that we all stop coding this GOTO garbage and
meet at Mo's for a beer.... I'm buying...


--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com

Re: Exceptions: Are they GOTOs?

[Spasmo]

Bradley Edelman (brad@cs.uwa.oz.au) wrote:
: What do people think about exception handling?  I believe it to be a major
: strength of Ada but there is a school of thought that exceptions are just
: GOTO statements and should be avoided accordingly.

Well, exceptions IMO do seem to be a bit unstructured in that control
is immediately transferred to another block and everything is surpassed
so that the possible paths of execution may not be obvious, however 
I think this is a very small price to pay for such a beautiful way of
handling errors.


: I think raising an exception is a neater way of handling an error than, say,
: returning an error code or status.

Full agreement.  There are 2 really great things that I love about
exceptions.
	1) They don't interfere with the regular return mechanisms of
	   subprogram units.  This was something that annoyed me to no
	   end in other languages.  If I had to account for error
	   returns, I'd have to cram it in with the other parameters or
	   return type of my subprogram which would play havoc with my
	   design, and often convolute things.  Furthermore there was
	   another problem which I'll talk about in #2.

	2) You can't ignore exceptions, and this is great because you
	   know that if you raise an exception, it WILL be handled.
	   Either the programmer on the other end will handle it, or
	   the system will take over, which will make the programmer
	   realize that there's an important return that he/she should
	   handle.  If you returned values from a procedure/function
	   then you had to face the possibility of your error code
	   being ignored.  This is especially serious in C/C++ since you
	   can happily ignore the return values from functions entirely,
	   calling them instead as if they were void functions.


: I'd appreciate thoughts either way.

All I can say is that I *LOVE* Ada's exceptions.  Hell, I like a lot
about Ada, but this is a thread about exceptions so I won't babble
here :)


: Thanks, Brad

--
Spasmo
"Here's a present just for you
When you open it, you'll be through"
	"Letter Bomb" by the Circle Jerks

Re: Exceptions: Are they GOTOs?

[David Morton]

Spasmo wrote:
> 
> Bradley Edelman (brad@cs.uwa.oz.au) wrote:
> : What do people think about exception handling?  I believe it to be a major
> : strength of Ada but there is a school of thought that exceptions are just
> : GOTO statements and should be avoided accordingly.
> 
> Well, exceptions IMO do seem to be a bit unstructured in that control
> is immediately transferred to another block and everything is surpassed
> so that the possible paths of execution may not be obvious, however
> I think this is a very small price to pay for such a beautiful way of
> handling errors.

again, that is the nature of an exception...  it may be a sort of goto
in this case:

procedure foo is
Something : exception;
begin

  raise something;

other stuff...
 exception 
   when something => oops;
end foo;

but, if the exception handler is not there,
then this isn't a goto, because the exception
propagates back down to the caller of this procedure.
That would mean the stack values being popped,
and any static variables being removed...
right?


exceptions are wonderful tools for handling an error.
Like Spasmo said, it's a heck of a lot easier than trying to
cram in another parameter or
worse, having the calling prog not check
for the error anyway...
exceptions do ensure that something will be done about the error.

-- 
David Morton
 mailto:dmorton@jinx.sckans.edu   http://www.sckans.edu/~dmorton/
 205 College, Winfield, KS 67156    
 This signature will self-destruct in 10 seconds...

Re: Exceptions: Are they GOTOs?

[Robert Dewar]

Spasmo said

"Well, exceptions IMO do seem to be a bit unstructured in that control
is immediately transferred to another block and everything is surpassed
so that the possible paths of execution may not be obvious, however
I think this is a very small price to pay for such a beautiful way of
handling errors."

This is an odd definition of structure, but if this is your definition
of structured, then I think your assumption that anything that is not
structured is bad is wrong. I know you go on to say that exceptions are
useful, but you should not accept even for a moment the orhodoxy that
such transfers of control are somehow unstructured and therefore inherently
bad! I assume you have read Knuth's paper :-)

Re: Exceptions: Are they GOTOs?

[Spasmo]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Spasmo said

: "Well, exceptions IMO do seem to be a bit unstructured in that control
: is immediately transferred to another block and everything is surpassed
: so that the possible paths of execution may not be obvious, however
: I think this is a very small price to pay for such a beautiful way of
: handling errors."

: This is an odd definition of structure, but if this is your definition
: of structured, then I think your assumption that anything that is not
: structured is bad is wrong. I know you go on to say that exceptions are
: useful, but you should not accept even for a moment the orhodoxy that
: such transfers of control are somehow unstructured and therefore inherently
: bad! I assume you have read Knuth's paper :-)

Well to me structure is when you can logically look at your code and
see where control is heading in a simple top down fashion.  Maybe
that's not the "proper" definition of structure *shrug*. As for
anything unstructured being automatically bad, I wouldn't say
that, however if I can do something, then if feasible I'll
try to do it using the structured technique.

I know that unstructured programming tends to have its applications
like in coding FAs straight from the diagram (easier to do with
gotos than anything else), it's just that in general I like to
avoid it if I can.

Am I a structured programming bigot??? :)


--
Spasmo
"Here's a present just for you
When you open it, you'll be through"
	"Letter Bomb" by the Circle Jerks

Re: Exceptions: Are they GOTOs?

[Walter B. Hollman Sr.]

If you will be the only person to maintain the code, use whatever you want;
but, using Goto can cause major problems for seasoned people trying to make
sense of your code. 
 
On Jul 17, 1996 22:49:11 in article <Re: Exceptions: Are they GOTOs?>,
'cosc19z5@Bayou.UH.EDU (Spasmo)' wrote: 
 
 
>Robert Dewar (dewar@cs.nyu.edu) wrote: 
>: Spasmo said 
> 
>: "Well, exceptions IMO do seem to be a bit unstructured in that control 
>: is immediately transferred to another block and everything is surpassed 
>: so that the possible paths of execution may not be obvious, however 
>: I think this is a very small price to pay for such a beautiful way of 
>: handling errors." 
> 
>: This is an odd definition of structure, but if this is your definition 
>: of structured, then I think your assumption that anything that is not 
>: structured is bad is wrong. I know you go on to say that exceptions are 
>: useful, but you should not accept even for a moment the orhodoxy that 
>: such transfers of control are somehow unstructured and therefore
inherently 
>: bad! I assume you have read Knuth's paper :-) 
> 
>Well to me structure is when you can logically look at your code and 
>see where control is heading in a simple top down fashion.  Maybe 
>that's not the "proper" definition of structure *shrug*. As for 
>anything unstructured being automatically bad, I wouldn't say 
>that, however if I can do something, then if feasible I'll 
>try to do it using the structured technique. 
> 
>I know that unstructured programming tends to have its applications 
>like in coding FAs straight from the diagram (easier to do with 
>gotos than anything else), it's just that in general I like to 
>avoid it if I can. 
> 
>Am I a structured programming bigot??? :) 
> 
> 
>-- 
>Spasmo 
>"Here's a present just for you 
>When you open it, you'll be through" 
>	"Letter Bomb" by the Circle Jerks 
> 
-- 
Walter B. Hollman Sr 
 
 
 
 
 
 
 

Re: Exceptions: Are they GOTOs?

[Robert Dewar]

Walter wrote:

"If you will be the only person to maintain the code, use whatever you want;
but, using Goto can cause major problems for seasoned people trying to make
sense of your code."

Walter, did you read the thread? What has this post to do with it (it is
of course true, and would be true for the substitution of practically
any other word for Goto). It certainly has nothing to do with whether
or not exceptions are gotos.

Perhaps it is just a mischievous troll to see if you can get this thread
to degenerated into yet another silly discussion of gotos (which I agre
it is perilously close to -- after all it had a very shaky foundation
to start with :-)

Re: Exceptions: Are they GOTOs?

[Robert Dewar]

Bradley said

"What do people think about exception handling?  I believe it to be a major
strength of Ada but there is a school of thought that exceptions are just
GOTO statements and should be avoided accordingly."

exceptions are quite different from goto's. See the original Ada 83
rationale
for a discussion of this issue.

Re: Exceptions: Are they GOTOs?

[Andy Askey]

brad@cs.uwa.oz.au (Bradley Edelman) wrote:

>What do people think about exception handling?  I believe it to be a major
>strength of Ada but there is a school of thought that exceptions are just
>GOTO statements and should be avoided accordingly.

>I think raising an exception is a neater way of handling an error than, say,
>returning an error code or status.

>I'd appreciate thoughts either way.

>Thanks, Brad

I have been writing Ada seriously for the past 3 years and have a few
opinions about exceptions:

1)  Exceptions are the best method of unexpected result handling that
I have used compared to other languages (the best but not perfect).
If a designer/coder develops code in small modular chunks, then there
is never any problem of determining execution flow in the event of an
exception.  Real time, mission critical software runs much better with
a language that has exception handling built in than a language such
as C where it is up to some coder to anticipate everything.

2) Exceptions do not work like GOTOs when used correctly.  The
internal mechanism is different and is much neater in many cases.  Too
much emphasis is placed on code with perfect structural integrity (no
GOTOs, EXITs, BREAKs, RETURNs, etc...)  If the code is written in
small modular blocks it is very easy to read.  Only my mentors, the
old FORTRAN hacks, can screw up the asthetic beauty of a 30 line
source module.

3)  Exceptions do work like GOTOs when used incorrectly.  For example:

  if x = 1 then
    raise The_Exception;
  else
    raise The_Other_Exception;
  end if;

God I hate code like this.  The coder should have just used GOTOs.  I
always spend hours trying to figure out some hidden anterior motive.
When I figure out it was some bored coder getting cute, it drives me
to the bottle.

4)  Exceptions can degrade performance if every couple of lines is
blocked and and exception handler added.  My ruler of thumb is that if
I really need a handler, I add it.  If it makes my life easier, I only
add it for debugging purposes.

I have only written "old" Ada.  If anything has changed with Ada95 as
far as exceptions are concerned, I would be very interested in hearing
about them.

--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com

Re: Exceptions: Are they GOTOs?

[Laurent Guerby]

[...]
Andy> I have only written "old" Ada.  If anything has changed with
Andy> Ada95 as far as exceptions are concerned, I would be very
Andy> interested in hearing about them.

   In Ada 95 you can associate a string message to an exception, and
there is a language defined package Ada.Exceptions, RM95-11.4.1, which
allows you to deal with "exception occurences". The syntax of
exceptions handlers has been a little extended:

exception
   when E : others => ...
        ^ name of the exception occurence

Andy> Andy Askey ajaskey@gnn.com

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Exceptions: Are they GOTOs?

[Andy Askey]

guerby@gnat.com (Laurent Guerby) wrote:

>   In Ada 95 you can associate a string message to an exception, and
>there is a language defined package Ada.Exceptions, RM95-11.4.1, which
>allows you to deal with "exception occurences". The syntax of
>exceptions handlers has been a little extended:

>exception
>   when E : others => ...
>        ^ name of the exception occurence

>Laurent Guerby <guerby@gnat.com>, Team Ada.
>   "Use the Source, Luke. The Source will be with you, always (GPL)."

This (the string message) sounds useful for debugging purposes, but it
seems to add a level of complexity to exceptions that would hurt
performance in a real time environment.
--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com

Re: Exceptions: Are they GOTOs?

[Robert Dewar]

Andy says

"This (the string message) sounds useful for debugging purposes, but it
seems to add a level of complexity to exceptions that would hurt
performance in a real time environment."

Not particularly, but then performance of *raising* an exception is not
something that can be counted on to be sparkling, in a real time
environment or otherwise. For example on the RS6000 the ABI specifies
a serial search of the code to find the exception table.

The whole idea of exceptions in Ada is to make them efficient when they
are NOT raised, if necessary at the expense of the behavior when they
*are* raised.

Re: Exceptions: Are they GOTOs?

[Robert Dewar]

Andy said

"2) Exceptions do not work like GOTOs when used correctly"

Actually, in my experience, Gotos do not work like Gotos when used correctly
:-) :-)

Re: Exceptions: Are they GOTOs?

[OS2 User]

	speaking about Reports vs GOTOs for Ada's exceptions,
	it is a false discussion.
GOTO
	Some of people say Exception = GOTO because they want to
        identify how the exception should work.

		------
		Instruction(s)
		Instruction >| exception |----.
		Instruction(s)                |
	       ------                         |
		 Handler <--------------------'
		   Selection & handling

	       ------                        (?)------->

	"Exceptions are GOTO" because it is like a jump to the
	exception handler (and even a dynamic jump throw several 
	levels).  In fact they identify the assumed exception 
        mechanisn and the exception.
	As say [Michel Gauthier]
        > The main difference between exception raise and goto is 
        >  that :
        >   - raising an exception is essentially declarative : 
        >     I assert that...
        >   - goto'ing (rather than 'going to') is imperative : 
        >     do this...	

	The goto must arise and the exception can hapend. 
	The GOTO must be in the same compilation unit, the 
	exception is made to be propagated.
	The Ada 95 exception have identity, occurence, message...
	Then I assert that GOTOs and exceptions are differents !


REPORT
        The report is a concept, it can be done using integer,boolean,
        message,... It signal that a software component cannot render 
	it service. To say I cannot render my service the first think 
	is to know 'what is the service' and how to make my report.
        Using report mut be done like this :

	Instruction =>Report
                 Report testing (?) handling (GOTO, Abort, ...)
        Instruction => ...

        The exception is just one implementation of the report signal.

	The advantages of Ada's exceptions are :
	o   the readability (two distinc parts for normal & handling)
        o   automating the report testing.
        o   the exception name (an user exception name should be explicit)
	o   the information transmited (with Ada 95)
	In Ada using control structures and Ada's exception all the exception 
	features (as described by goodenough 75) can be done :
	o   Abort     (Default)
        o   Retry     (With or not treatment)
	o   Continue  ( //     //    //     )
	   
	For these previous reasons, I assert than the exception is the 
	best way to implement report in Ada. But the exception is not
	the report. The report should be made specifying pre-, post-,
	and report-conditions to be usefull. 

OTHERS ( My own opignon)

	But exception is not the report is just it signal, like paper for
	news. Ada's exception is just a language tool to signal. The
	name "exception" help some of us to say exception must be used only
	for exceptionnal state. I am not agree with this !
	I think that Ada's exceptions can be use as a signal to break the 
	normal flow. Doing this, we _must_ be sure that using an exception
	is made in a safe way. 
	If you use only one file, why do you need to test the End_Of_File
	exception can make this for you ! The code is buggy only if the
	exception is _not_ expected. (If you use a offensive programming
	style, you must verify every pre-condition and for you you cannot
	expect this End_Of_File, your code can be buggy in this sense).
        One of the most popular example is the protected get.
	     PROTECTED_GET: loop
		  begin
	            Get( MY_DATA );
		    Skip_Line;
		    exit PROTECTED_GET;
                  exception 
                    when DATA_ERROR | CONTRAINT_ERROR =>
                        Skip_Line;
			Put_Line("Another try");
                    when others =>
			Put_Line(" Abnormal Error ");
			raise;
                  end;
             end loop; 
	I apreciate to know, how to verify that the user is going to
	enter a bad value ;-)
	the using exception dificulty is to identify each raise and
	to expect each of them. Guideline are usefull, they could be
	applied but we must know why to do this.
	The new Ada'95 exception mechanism is more complex than the previous 
	one, but it permit to handle exception in more complicated 
	situations. If we do not use it, we do not complexify the treatment ;
	but if we use it, It must be because we need it. 
	
	

--

					Christophe Faure

	 _______________________________________________________
	|	               *	   # #      ###    #    |
	|  Christophe FAURE     *         # # #  @  #  @  # @   |
	|  Tel :+33()55.45.72.32 *       #     #  ###    #      | 
	|  Fax :+33()55.45.73.15  *                             |
	|        		   *     Laboratoire M.S.I    	|
	|  e-mail : Faure@unilim.fr *    Universite de Limoges	|
	|			     *   F-87060 LIMOGES	|
	|_______________________________________________________|

Re: Exceptions: Are they GOTOs?

[Michel Gauthier]

In article <4s9o6e$ro4@news-e2b.gnn.com>, ajaskey@gnn.com (Andy Askey) wrote:

>>  [...]
>>  I have only written "old" Ada.  If anything has changed with Ada95 as
>>  far as exceptions are concerned, I would be very interested in hearing
>>  about them.

There is a paper in the January, 1995 (if my memory is right) issue of
the ACM Ada Letters about these changes.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

Re: Exceptions: Are they GOTOs?

[Michel Gauthier]

This is a reply to a private message following a c.l.a message in which
<brad.837052481@ss1>, brad@cs.uwa.oz.au (Bradley Edelman) wrote:

>>>  What do people think about exception handling?  I believe it to be a major
>>>  strength of Ada but there is a school of thought that exceptions are just
>>>  GOTO statements and should be avoided accordingly.

The following ideas are milestones, rather than a well-built paper.

"resuming requirement" : some projects require appropriate reactions
     after any situation, including bad ones. Other projects may 
     locally encounter the same requirement (basic case : syntax
     errors in typing input data).

"reuse principle 1" : a reusable component is not allowed to make
     assumptions about its uses.
       Consequently : it is not allowed to assume anything about
     'normality' or 'abnormality' of calls.
       The only things a reusable component may do are rendering 
     the service it has to, or reporting that it cannot.

Consequence : aborts and goto's are not suitable to report, since they
     assume too much things about the use.

Known vocabulary : programming is 'offensive' when the caller has to
     check some precondition that permits the callee to work correctly,
     and 'defensive' when the callee checks the preconditions and
     reports accordingly if it cannot work correctly.
       'Offensiveness' is a property of each caller. 'Defensiveness' is 
     a property of the callee. Some calls can be both.

Consequence : the 'defensive' behaviour is the only possible
     one for a reusable component, since the contrary assumes that all
     callers are 'offensive'.
       Of course, there is no harm in non-defensive behaviour when
     the programmer has a full control on a well-defined set of calls.

Known implementations of reports : exceptions and status codes.
       Balance : status codes imply verbosity caused by the requirement
     of explicit handling everywhere in the program, exceptions imply 
     implicit information, which has to be made explicit by re-building
     or by appropriate documentation.
       IMHO : exceptions are simpler in most cases, not necessarily
     in all cases (remind that we speak of reusable components only).
       To convince yourself, consider what you would have to write
     if Text_IO was specified with status codes, and the quality
     of the resulting programs.

Complexity of goto's : very long ago, I wrote a paper about measuring
     (in McCabe's style) the effect of transforming non-'structured'
     algorithms into 'structured' ones. More generally, it may be interesting
     to measure the effect of program-transforming algorithms. About
     goto's, the result was :
      - additional complexity of forward-goto's : the number of control
     structures that the jump exits from
      - additional complexity of one backward goto : the above, plus
     an enclosing loop
      - additional complexity of mixed forward and backward goto's :
     not computable, since the transformation involves copying pieces
     of source text.
       According to this idea, exception raise and handling is
     exactly like forward-goto's (with any language, except Eiffel's 
     'retry'). Be aware that this complexity _is_ in the program, whether
     you handle exceptionsor not.
       Note : this seems to illustrate that exceptions are less complex
     than status codes, which work as transformation of exceptions into
     'structured' code (status introduces flows that converge, goes
     together during a time, and then diverge again).

Ambiguity of 'contract' : the idea that a specification is a sort of
     contract (in the commercial sense) between a client and a
     provider is a very old idea. I remember that I, and other colleagues,
     was already using it in my courses (using Pascal and status) in 1975.
       However, it is ambiguous whether the word 'contract' denotes
     the expected service in a limited sense, or the behaviour in all
     cases. The renowned (but IMHO somewhat weak) Bertrand Meyer's book 
     is ambiguous too. There are two concepts, we need two words.

_Remind that_ : almost every statement and many declarations
     can raise at least one exception. Languages that do not provide 
     such control are not dependable.

Suggestion : call 'specification' the definition of the basic service,
     and 'contact' the full definition with report cases. Also call
     'success' the case of obtaining the specification, and 'failure'
     the contrary. Do not call of 'errors' here.
       Remember that preconditions can sometimes not be coded as
     predicate functions : opening a remote file (can be, but implies
     a non-atomic statement), inversing a matrix (same complexity as
     the basic computation), getting a number from the user
     (intrinsically impossible),... The issue of numeric compotations
     and overflowing is intrinsically impossible, too.
       Of course, the so-called 'contract model' of genericity is 
     compatible with this choice of words.

Very important : "success vs. failure" / "correct vs. erroneous" /
     "exception vs. status" are entirely independent distinctions :
     you can find examples of the eight possible cases (although one
     of the eight is somewhat exotic, but sometimes required).
       Particularly : yileding a result when a report is required by
     the specification is an error !!!

"raising is simple" : in most cases, you are inside one or more branches
     of conditional statements (or cases, or loops), which builds a rich
     knowledge of the program state, and permits you decide that it is 
     a situation where the contract requires a raise.
       The same holds with status codes, and goto'ing is similar.

"handling can be complex" : a handler is a location where many flows
     converge. There are many risks of errors here :
     - if your mind omits one corresponding raise,
     - if you have not enough information about the program state at the
     locations of the raises.
       Useful rules can be deduced from this :
     - compute the exact set of raises,
     - prove appropriately if some raises cannot be reached,
     - attach postconditions to exception raise locations as well as to
     any other subprogram exit.
       There is, of course, always the risk of bad proofs, but nothing
     will never decrease this risk to zero.

Caution for status codes : the equivalent (with exceptions) of
                         if REPORT /= SOME_REPORT then
                              SUCC ;
                         else
                              FAIL ;
                         end if ;
     will include something like :
                         when SOME_REPORT =>
                              FAIL ;
                         when others =>  -- ???
                              SUCC ;      -- ???
     Dangerous, isn't it ?

Yet more rules : in fact, a good use of reports requires the above 
     rules for _all_ reports, whether reporting is by exceptions or
     by status codes. Hence, for a piece of program (say, subprogram) :
     - consider _all_ raises, including implicit ones, or assignments of 
     the status,
     - remove all non-reachable raises of this set, after proving it,
     - consider all reports allowed in the contact,
     - check if internal effective raises and final reports fit,
     - every non-fit detects a programming error.

Sorry, but : without such style rules, how can you depend on a program ?

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------