Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
etiology of exceptions
73 views
Skip to first unread message
bob
Sep 25, 2012, 10:29:21 AM9/25/12
to
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?
Daniel Pitts
Sep 25, 2012, 12:15:13 PM9/25/12
to
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.
> 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?
>
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.
Dmitry A. Kazakov
Sep 25, 2012, 12:50:53 PM9/25/12
to
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
> 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.
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
Willem
Sep 25, 2012, 4:51:56 PM9/25/12
to
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
) 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
Daniel Pitts
Sep 25, 2012, 6:32:35 PM9/25/12
to
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.
> 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
> 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.
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.
James Dow Allen
Sep 26, 2012, 2:43:08 AM9/26/12
to
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
> 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?
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
Chris Uppal
Sep 28, 2012, 3:07:25 AM9/28/12
to
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
Rui Maciel
Sep 28, 2012, 4:47:38 AM9/28/12
to
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.
> 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
Rui Maciel
jussi....@ard.fi
Oct 8, 2012, 2:13:48 AM10/8/12
to
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?
> 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?
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
LudovicoVan
Oct 8, 2012, 5:37:19 PM10/8/12
to
Ian Collins
Oct 8, 2012, 5:46:00 PM10/8/12
to
--
Ian Collins
LudovicoVan
Oct 8, 2012, 5:52:18 PM10/8/12
to
"Ian Collins" <ian-...@hotmail.com> wrote in message
news:adgvso...@mid.individual.net...
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
news:adgvso...@mid.individual.net...
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
Nick Keighley
Oct 10, 2012, 11:06:05 AM10/10/12
to
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
> 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
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
> -exception do not add to program correctness, but to robustness (operation out of specifications)
specification (though C++ has problems with this)
LudovicoVan
Oct 10, 2012, 1:24:19 PM10/10/12
to
"Nick Keighley" <nick_keigh...@hotmail.com> wrote in message
news:02c3ed18-a81a-4ae0...@k6g2000vbr.googlegroups.com...
>> -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
news:02c3ed18-a81a-4ae0...@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>
>> tiistai, 25. syyskuuta 2012 17.29.21 UTC+3 bob kirjoitti:
>> -exception are no program flow cotrol structures
>
> probably
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)
This might be clearer if we think, for instance, of the case of accessing an
external API.
-LV
Nick Keighley
Oct 11, 2012, 8:35:23 AM10/11/12
to
On Oct 10, 6:24 pm, "LudovicoVan" <ju...@diegidio.name> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
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
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
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
LudovicoVan
Oct 11, 2012, 9:40:02 AM10/11/12
to
"Nick Keighley" <nick_keigh...@hotmail.com> wrote in message
news:0eed1afd-7a29-4b46...@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++
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
Rui Maciel
Oct 11, 2012, 10:35:06 AM10/11/12
to
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
>> >> -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
catching exceptional events which are themselves exceptional.
Rui Maciel
Nick Keighley
Oct 11, 2012, 11:20:16 AM10/11/12
to
On Oct 11, 2:40 pm, "LudovicoVan" <ju...@diegidio.name> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
yes I got that, hence I pointed out we can specify the exceptional
behaviour by means other than C++'s exception specifications
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
behaviour by means other than C++'s exception specifications
Nick Keighley
Oct 11, 2012, 11:21:14 AM10/11/12
to
jussi....@ard.fi
Oct 15, 2012, 11:10:18 AM10/15/12
to
keskiviikko, 10. lokakuuta 2012 18.06.05 UTC+3 Nick Keighley kirjoitti:
> 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.
>
At the same time you are giving up one of the few major achievements of CS: structured programming. Exceptions are allowed when already out of specification.
> 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.
>
Yes, assertions when evaluated at runtime are one means of detecting programmer errors and hence complete failure.
>
> 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)
And the idea (exceptions as part of specification) is controversial in other languages.
>
> > -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)
jussi....@ard.fi
Oct 15, 2012, 11:28:01 AM10/15/12
to
br Jussi
>
>
> -LV
LudovicoVan
Oct 15, 2012, 5:13:41 PM10/15/12
to
<jussi....@ard.fi> wrote in message
news:72efd5d6-d0d0-4412...@googlegroups.com...
>> > 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
news:72efd5d6-d0d0-4412...@googlegroups.com...
> torstai, 11. lokakuuta 2012 16.40.10 UTC+3 Julio P. Di Egidio kirjoitti:
>> "Nick Keighley" <nick_keigh...@hotmail.com> wrote in message
<snip>
>> "Nick Keighley" <nick_keigh...@hotmail.com> wrote in message
>> > 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.
about remains quite irrelevant to the OP.
-LV
LudovicoVan
Oct 15, 2012, 5:16:08 PM10/15/12
to
<jussi....@ard.fi> wrote in message
news:1324fb43-38f5-4d09...@googlegroups.com...
-LV
news:1324fb43-38f5-4d09...@googlegroups.com...
> keskiviikko, 10. lokakuuta 2012 18.06.05 UTC+3 Nick Keighley kirjoitti:
>> 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.
>
> At the same time you are giving up one of the few major achievements of
> CS: structured programming. Exceptions are allowed when already out of
> specification.
Pure bollocks. Well done.
>> 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.
>
> At the same time you are giving up one of the few major achievements of
> CS: structured programming. Exceptions are allowed when already out of
> specification.
-LV
Ǝ
Aug 4, 2023, 6:58:34 AM8/4/23
to
0 new messages