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 2 of 2 — ← Prev page 1 [2]

#2324

On Oct 11, 3:35 pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> 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.

its nice to know which exceptions are likely to be thrown

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

#2346

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.
> 
> 
> You might be thinking of assertions.
> 
Yes, assertions when evaluated at runtime are one means of detecting programmer errors and hence complete failure.
> 
> 
> > -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.

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

#2350

<jussi.santti@ard.fi> wrote in message 
news:1324fb43-38f5-4d09-b12a-63b6e68b42d3@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.

-LV
 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.programming

csiph-web