Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2240 > unrolled thread

etiology of exceptions

Back to article view | Back to comp.programming

Contents

  etiology of exceptions bob <bob@coolfone.comze.com> - 2012-09-25 07:29 -0700
    Re: etiology of exceptions Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-25 09:15 -0700
      Re: etiology of exceptions "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-09-25 18:50 +0200
      Re: etiology of exceptions Willem <willem@turtle.stack.nl> - 2012-09-25 20:51 +0000
        Re: etiology of exceptions Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-25 15:32 -0700
    Re: etiology of exceptions James Dow Allen <jdallen2000@yahoo.com> - 2012-09-25 23:43 -0700
    Re: etiology of exceptions "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-09-28 08:07 +0100
      Re: etiology of exceptions Rui Maciel <rui.maciel@gmail.com> - 2012-09-28 09:47 +0100
    Re: etiology of exceptions jussi.santti@ard.fi - 2012-10-07 23:13 -0700
      Re: etiology of exceptions "LudovicoVan" <julio@diegidio.name> - 2012-10-08 22:37 +0100
        Re: etiology of exceptions Ian Collins <ian-news@hotmail.com> - 2012-10-09 10:46 +1300
          Re: etiology of exceptions "LudovicoVan" <julio@diegidio.name> - 2012-10-08 22:52 +0100
      Re: etiology of exceptions Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-10 08:06 -0700
        Re: etiology of exceptions "LudovicoVan" <julio@diegidio.name> - 2012-10-10 18:24 +0100
          Re: etiology of exceptions Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-11 05:35 -0700
            Re: etiology of exceptions "LudovicoVan" <julio@diegidio.name> - 2012-10-11 14:40 +0100
              Re: etiology of exceptions Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-11 08:20 -0700
              Re: etiology of exceptions jussi.santti@ard.fi - 2012-10-15 08:28 -0700
                Re: etiology of exceptions "LudovicoVan" <julio@diegidio.name> - 2012-10-15 22:13 +0100
            Re: etiology of exceptions Rui Maciel <rui.maciel@gmail.com> - 2012-10-11 15:35 +0100
              Re: etiology of exceptions Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-11 08:21 -0700
        Re: etiology of exceptions jussi.santti@ard.fi - 2012-10-15 08:10 -0700
          Re: etiology of exceptions "LudovicoVan" <julio@diegidio.name> - 2012-10-15 22:16 +0100

Page 1 of 2  [1] 2  Next page →

#2240 — etiology of exceptions

What is the etiology of exceptions?  Did they come about because people got tired of having to check a return value every time they called a function?

[toc] | [next] | [standalone]

#2242

On 9/25/12 7:29 AM, bob wrote:
> What is the etiology of exceptions?  Did they come about because people got tired of having to check a return value every time they called a function?
>
I don't know of how they came to be, but I can list several benefits.

1. The Error Condition and the Error Handler which-could-handle-it were 
often separated by several levels of calls.

2. Having a "magic" return value isn't always possible, or desirable, so 
some other mechanism needed to be employed.  Passing an argument by 
reference has additional overhead for a hopefully rare case.

3. In some languages, Exceptions can be compile-time checked, which 
helps reduce the number of bugs.  The compiler can even use its typing 
system to ensure that the *correct* exceptions are handled, further 
reducing human error.

4. Exceptions also allow easy polymorphism of error cases. Because of 
this, they are useful in more OO design patterns over simple return values.

5. In complicated programs, it is easier to visualize flow of execution 
with fewer "if" statements.  Using exceptions allows easier 
understanding of the "normal" flow vs "exceptional" flow.  It also helps 
to understand what code is actually responsible for handling error 
conditions (since its concentrated in the catch blocks).

This is all just off the top of my head, and some of it may be arguable, 
but IMHO the argument that you can just check return values is flawed. 
You *can* just check return values, just as you *can* turn off a 
light-bulb by unscrewing it.  There just is a better way.

[toc] | [prev] | [next] | [standalone]

#2243

On Tue, 25 Sep 2012 09:15:13 -0700, Daniel Pitts wrote:

> This is all just off the top of my head, and some of it may be arguable, 
> but IMHO the argument that you can just check return values is flawed. 
> You *can* just check return values, just as you *can* turn off a 
> light-bulb by unscrewing it.  There just is a better way.

6. Performance, if nested calls all are checking return values this may
lead to significant overhead. Exceptions move the balance towards more
expensive execution in the case of rare exceptional cases for the sake of
more lightweight execution when everything is OK. For example, checking for
the file end may be omitted in the body of a loop that reads the file out.
The file end is caught by an exception handler. There only one file and
successful reads before it reached.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2246

Daniel Pitts wrote:
) On 9/25/12 7:29 AM, bob wrote:
)> What is the etiology of exceptions?  Did they come about because people
)> got tired of having to check a return value every time they called a
)> function?
)>
) I don't know of how they came to be, but I can list several benefits.
)
) 1. The Error Condition and the Error Handler which-could-handle-it were 
) often separated by several levels of calls.
)
) 2. Having a "magic" return value isn't always possible, or desirable, so 
) some other mechanism needed to be employed.  Passing an argument by 
) reference has additional overhead for a hopefully rare case.
)
) 3. In some languages, Exceptions can be compile-time checked, which 
) helps reduce the number of bugs.  The compiler can even use its typing 
) system to ensure that the *correct* exceptions are handled, further 
) reducing human error.
)
) 4. Exceptions also allow easy polymorphism of error cases. Because of 
) this, they are useful in more OO design patterns over simple return values.
)
) 5. In complicated programs, it is easier to visualize flow of execution 
) with fewer "if" statements.  Using exceptions allows easier 
) understanding of the "normal" flow vs "exceptional" flow.  It also helps 
) to understand what code is actually responsible for handling error 
) conditions (since its concentrated in the catch blocks).
)
) This is all just off the top of my head, and some of it may be arguable, 
) but IMHO the argument that you can just check return values is flawed. 
) You *can* just check return values, just as you *can* turn off a 
) light-bulb by unscrewing it.  There just is a better way.

Those are good reasons to have exception checking, but none of that answers
the question.  What the OP wants to know is what was the birth of exception
checking.  What is the history, how did it come about, etc.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#2248

On 9/25/12 1:51 PM, Willem wrote:
> Daniel Pitts wrote:
> ) On 9/25/12 7:29 AM, bob wrote:
> )> What is the etiology of exceptions?  Did they come about because people
> )> got tired of having to check a return value every time they called a
> )> function?
> )>
> ) I don't know of how they came to be, but I can list several benefits.
> Those are good reasons to have exception checking, but none of that answers
> the question.  What the OP wants to know is what was the birth of exception
> checking.  What is the history, how did it come about, etc.

As you can see, that was acknowledged at the beginning of my post. I 
wasn't around at the inception of exceptions, but I could imagine any 
one of those ideas being the precursor.

More likely was some project somewhere had basically invented the 
concept because of business requirements, possibly using longjmp in c, 
and then the other developers asked for language-level support of the 
concept.

This is, of course, all conjecture on my part.

Also, the phrasing of the original question was showing bias on the 
topic, so I thought I'd add bias in the opposite direction to help even 
out the discussion.

[toc] | [prev] | [next] | [standalone]

#2250

On Sep 25, 9:29 pm, bob <b...@coolfone.comze.com> wrote:
> What is the etiology of exceptions?  Did they come about because people got tired of having to check a return value every time they called a function?

The use of software-raised exceptions surely arose in imitation
of hardware-raised exceptions, i.e. traps and interrupts.

Here's an article which claims that fixed-arithmetic overflow trap
on Univac-I in 1951 was the first hardware trap.
   http://www.cs.clemson.edu/~mark/interrupts.html

Here's an article by John McCarthy on his suggestion
that a new trap be added to IBM mainframe in 1957:
  http://www-formal.stanford.edu/jmc/history/timesharing/timesharing.html

James Dow Allen

[toc] | [prev] | [next] | [standalone]

#2258

bob wrote:
> What is the etiology of exceptions?  Did they come about because people
> got tired of having to check a return value every time they called a
> function?

If you're interested in the history, you might read:

    Goodenough J. B.: Exception Handling: Issues and a Proposed Notation.
    CACM 1975, vol 18, number 12

and several of the references look relevant too.

Can be got from:

    http://www.cs.virginia.edu/~weimer/2007-615/reading/goodenough-exceptions.pdf

    -- chris 

[toc] | [prev] | [next] | [standalone]

#2259

Chris Uppal wrote:

> If you're interested in the history, you might read:
> 
> Goodenough J. B.: Exception Handling: Issues and a Proposed Notation.
> CACM 1975, vol 18, number 12
> 
> and several of the references look relevant too.
> 
> Can be got from:
> 
> http://www.cs.virginia.edu/~weimer/2007-615/reading/goodenough-
exceptions.pdf

Excellente read.  Thanks for pointing it out.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2294

tiistai, 25. syyskuuta 2012 17.29.21 UTC+3 bob kirjoitti:
> What is the etiology of exceptions? Did they come about because people got tired of having to check a return value every time they called a function?

Not answering the etiology of exceptions question, sorry. But a related question: What is the best understanding of their role after 40+ years?
Let me try:
-exceptions for programmer errors only
-exceptions should be reserved for complete failures 
-exception are no program flow cotrol structures
-exception do not add to program correctness, but to robustness (operation out of specifications)

br Jussi

[toc] | [prev] | [next] | [standalone]

#2296

<jussi.santti@ard.fi> wrote in message 
news:902b53ef-fa30-4470-914f-a5d3bf904b60@googlegroups.com...
> tiistai, 25. syyskuuta 2012 17.29.21 UTC+3 bob kirjoitti:
>> What is the etiology of exceptions? Did they come about because people 
>> got tired of having to check a return value every time they called a 
>> function?
>
> Not answering the etiology of exceptions question, sorry. But a related 
> question: What is the best understanding of their role after 40+ years?
> Let me try:
>
> -exceptions for programmer errors only
> -exceptions should be reserved for complete failures
> -exception are no program flow cotrol structures
> -exception do not add to program correctness, but to robustness (operation 
> out of specifications)

Not so.

-LV
 

[toc] | [prev] | [next] | [standalone]

#2297

On 10/09/12 10:37, LudovicoVan wrote:
> <jussi.santti@ard.fi>  wrote in message
> news:902b53ef-fa30-4470-914f-a5d3bf904b60@googlegroups.com...
>> tiistai, 25. syyskuuta 2012 17.29.21 UTC+3 bob kirjoitti:
>>> What is the etiology of exceptions? Did they come about because people
>>> got tired of having to check a return value every time they called a
>>> function?
>>
>> Not answering the etiology of exceptions question, sorry. But a related
>> question: What is the best understanding of their role after 40+ years?
>> Let me try:
>>
>> -exceptions for programmer errors only
>> -exceptions should be reserved for complete failures
>> -exception are no program flow cotrol structures
>> -exception do not add to program correctness, but to robustness (operation
>> out of specifications)
>
> Not so.

Now there's a well presented argument.....

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2298

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:adgvsoFp4lcU3@mid.individual.net...
> On 10/09/12 10:37, LudovicoVan wrote:
>> <jussi.santti@ard.fi>  wrote in message
>> news:902b53ef-fa30-4470-914f-a5d3bf904b60@googlegroups.com...
>>> tiistai, 25. syyskuuta 2012 17.29.21 UTC+3 bob kirjoitti:
>>>> What is the etiology of exceptions? Did they come about because people
>>>> got tired of having to check a return value every time they called a
>>>> function?
>>>
>>> Not answering the etiology of exceptions question, sorry. But a related
>>> question: What is the best understanding of their role after 40+ years?
>>> Let me try:
>>>
>>> -exceptions for programmer errors only
>>> -exceptions should be reserved for complete failures
>>> -exception are no program flow cotrol structures
>>> -exception do not add to program correctness, but to robustness 
>>> (operation
>>> out of specifications)
>>
>> Not so.
>
> Now there's a well presented argument.....

Where is it? :)  Out of metaphor (so to say), if you try and negate the 
above assertions, you'll get, I think, pretty much acceptable ones.  It 
seemed so much done on purpose that I fear I am spoiling something...

-LV
 

[toc] | [prev] | [next] | [standalone]

#2301

On Oct 8, 7:13 am, jussi.san...@ard.fi wrote:
> tiistai, 25. syyskuuta 2012 17.29.21 UTC+3 bob kirjoitti:
>
> > What is the etiology of exceptions? Did they come about because people got tired of having to check a return value every time they called a function?
>
> Not answering the etiology of exceptions question, sorry. But a related question: What is the best understanding of their role after 40+ years?
> Let me try:
> -exceptions for programmer errors only
> -exceptions should be reserved for complete failures

no to both of these. I've used exceptions to exit from deeply nested
parsers. There is no point in propagating an error through the various
calls and it makes everything more complicated.

You might be thinking of assertions.

> -exception are no program flow cotrol structures

probably

> -exception do not add to program correctness, but to robustness (operation out of specifications)

the exceptions a function may throw could be thought of as part of its
specification (though C++ has problems with this)

[toc] | [prev] | [next] | [standalone]

#2307

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message 
news:02c3ed18-a81a-4ae0-b03d-666bc239d862@k6g2000vbr.googlegroups.com...
> On Oct 8, 7:13 am, jussi.san...@ard.fi wrote:
>> tiistai, 25. syyskuuta 2012 17.29.21 UTC+3 bob kirjoitti:
<snip>

>> -exception are no program flow cotrol structures
>
> probably

But they do alter/contribute to the program flow (I mean, even when used 
properly).  To the point that we do model that flow, say, in a unit 
functional diagram.

>> -exception do not add to program correctness, but to robustness 
>> (operation out of specifications)
>
> the exceptions a function may throw could be thought of as part of its
> specification (though C++ has problems with this)

If it is not in the spec, it is not an exception in the technical sense. 
This might be clearer if we think, for instance, of the case of accessing an 
external API.

-LV
 

[toc] | [prev] | [next] | [standalone]

#2320

On Oct 10, 6:24 pm, "LudovicoVan" <ju...@diegidio.name> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
>
> news:02c3ed18-a81a-4ae0-b03d-666bc239d862@k6g2000vbr.googlegroups.com...> On Oct 8, 7:13 am, jussi.san...@ard.fi wrote:
> >> tiistai, 25. syyskuuta 2012 17.29.21 UTC+3 bob kirjoitti:
>
> <snip>
>
> >> -exception are no program flow cotrol structures
>
> > probably
>
> But they do alter/contribute to the program flow (I mean, even when used
> properly).  To the point that we do model that flow, say, in a unit
> functional diagram.
>
> >> -exception do not add to program correctness, but to robustness
> >> (operation out of specifications)
>
> > the exceptions a function may throw could be thought of as part of its
> > specification (though C++ has problems with this)
>
> If it is not in the spec, it is not an exception in the technical sense.
> This might be clearer if we think, for instance, of the case of accessing an
> external API.

the difficulty is that exception specifications are broken in C++

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3051.html
(that's just the first hit I got looking for "C++ exception problem")

If you are specifying an API then the exceptions that may thrown are
usually documented (eg. with comments) but not by using exception
specifications

[toc] | [prev] | [next] | [standalone]

#2321

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message 
news:0eed1afd-7a29-4b46-b990-0ee9d988c76d@ib4g2000vbb.googlegroups.com...
> On Oct 10, 6:24 pm, "LudovicoVan" <ju...@diegidio.name> wrote:
<snip>

>> If it is not in the spec, it is not an exception in the technical sense.
>> This might be clearer if we think, for instance, of the case of accessing 
>> an
>> external API.
>
> the difficulty is that exception specifications are broken in C++

You are using "specification" in a very specific technical sense, but I was 
referring to the formal documentation that must go with any product, 
regardless of implementation details.  And the overall point was that an 
exception is, *by definition*, something we *do* forecast.

-LV
 

[toc] | [prev] | [next] | [standalone]

#2323

On Oct 11, 2:40 pm, "LudovicoVan" <ju...@diegidio.name> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
>
> news:0eed1afd-7a29-4b46-b990-0ee9d988c76d@ib4g2000vbb.googlegroups.com...> On Oct 10, 6:24 pm, "LudovicoVan" <ju...@diegidio.name> wrote:
>
> <snip>
>
> >> If it is not in the spec, it is not an exception in the technical sense.
> >> This might be clearer if we think, for instance, of the case of accessing
> >> an
> >> external API.
>
> > the difficulty is that exception specifications are broken in C++
>
> You are using "specification" in a very specific technical sense, but I was
> referring to the formal documentation that must go with any product,
> regardless of implementation details.  And the overall point was that an
> exception is, *by definition*, something we *do* forecast.

yes I got that, hence I pointed out we can specify the exceptional
behaviour by means other than C++'s exception specifications

[toc] | [prev] | [next] | [standalone]

#2347

torstai, 11. lokakuuta 2012 16.40.10 UTC+3 Julio P. Di Egidio kirjoitti:
> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message 
> 
> news:0eed1afd-7a29-4b46-b990-0ee9d988c76d@ib4g2000vbb.googlegroups.com...
> 
> > On Oct 10, 6:24 pm, "LudovicoVan" <ju...@diegidio.name> wrote:
> 
> <snip>
> 
> 
> 
> >> If it is not in the spec, it is not an exception in the technical sense.
> 
> >> This might be clearer if we think, for instance, of the case of accessing 
> 
> >> an
> 
> >> external API.
> 
> >
> 
> > the difficulty is that exception specifications are broken in C++
> 
> 
> 
> You are using "specification" in a very specific technical sense, but I was 
> 
> referring to the formal documentation that must go with any product, 
> 
> regardless of implementation details.  And the overall point was that an 
> 
> exception is, *by definition*, something we *do* forecast.
> 
When we talk about C++ and other common languages, the specifications are in the form of function prototypes.

br Jussi 
> 
> 
> -LV

[toc] | [prev] | [next] | [standalone]

#2349

<jussi.santti@ard.fi> wrote in message 
news:72efd5d6-d0d0-4412-882d-c5e33cea45dd@googlegroups.com...
> torstai, 11. lokakuuta 2012 16.40.10 UTC+3 Julio P. Di Egidio kirjoitti:
>> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
<snip>

>> > the difficulty is that exception specifications are broken in C++
>>
>> You are using "specification" in a very specific technical sense, but I 
>> was
>> referring to the formal documentation that must go with any product,
>> regardless of implementation details.  And the overall point was that an
>> exception is, *by definition*, something we *do* forecast.
>>
> When we talk about C++ and other common languages, the specifications are 
> in the form of function prototypes.

Thanks for explaining what was already understood.  OTOH, what you talk 
about remains quite irrelevant to the OP.

-LV
 

[toc] | [prev] | [next] | [standalone]

#2322

Nick Keighley wrote:

>> >> -exception do not add to program correctness, but to robustness
>> >> (operation out of specifications)
>>
>> > the exceptions a function may throw could be thought of as part of its
>> > specification (though C++ has problems with this)
>>
>> If it is not in the spec, it is not an exception in the technical sense.
>> This might be clearer if we think, for instance, of the case of accessing
>> an external API.
> 
> the difficulty is that exception specifications are broken in C++
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3051.html
> (that's just the first hit I got looking for "C++ exception problem")
> 
> If you are specifying an API then the exceptions that may thrown are
> usually documented (eg. with comments) but not by using exception
> specifications

That isn't exactly a major issue.  A catch(...){} block is quite capable of 
catching exceptional events which are themselves exceptional.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web