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

Groups > comp.lang.c++ > #12283

Re: C++ standard library and exceptions

Show all headers | View raw

On 08-12-2011 PM 06:38, Goran wrote:
> On Dec 8, 12:05 pm, ittium<itt...@gmail.com>  wrote:
>> On 12/8/2011 2:32 PM, Goran wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Dec 8, 7:47 am, ittium<itt...@gmail.com>    wrote:
>>>> Groups,
>>>> I have been using C++ for last couple of years, only exception from
>>>> standard library (+STL) that I ever worried was bad_alloc from new.
>>>> Lately I have been reading about exception and It appears large numbers
>>>> of routine can throw exception.
>>
>>> Yes, however, AFAIK, all of them throws indicate a serious bug in your
>>> program. Do you want to continue running even though you stepped on a
>>> bug? I think not.
>>
>>> The only potential exception I know of is vector resize, when you
>>> might get length_error because elem_size*elem_count if over address
>>> space size.
>>
>>>> I was wondering what is the best way to
>>>> find out the list of exception a standard library routine can throw.
>>
>>> I don't know, but I know this: that's the wrong way of working with
>>> exceptions. In a vast majority of cases you simply don't want to know
>>> what exception types are. What you do need, though, is whether some
>>> routine can throw or not (and even that, not that often, only when you
>>> have a piece of no-throw code and you do work with some STL element in
>>> it).
>>
>>> Could you given an example of why you think it's important to know the
>>> type of the exception? I'll try to show you how to do it so that it
>>> isn't.
>>
>>>> I
>>>> am actually looking for **some kind** of standard man pages, that talks
>>>> about exceptions apart from method signatures and return values.
>>
>>> I know of none. But, due to what I think about that, see above, I
>>> didn't look very hard.
>>
>>> Further, I believe that specifying such a list would hinder further
>>> development of the library, and would also hinder what's available to
>>> implementation to e.g. improve debugging facilities. If such list was
>>> prescribed, you might easily get have non-compliant error-checking
>>> facilities checks in a debug version (or even in release), or make
>>> creation/use of such facilities harder.
>>
>>> Goran.
>>
>> Thanks Goran, for a very detailed explanation. Please correct me if I am
>> wrong. This is what you are saying
>>
>> It is not a good idea to catch the exception thrown from standard
>> library routine,
>
> Actually, I would say "it's a bad idea to catch any exception" ;-),
> for the very reason you state just below (there's no recovery). I
> usually say "when you think you need to catch an exception, don't; see
> what happens when it's thrown and where you end up. Only if you don't
> like that, catch. I don't see a big difference between an exception
> thrown by a standard library, and one of your own.
>
> Here's how I see things: code runs doing some operation. During that
> operation, exception happens. In a vast (VAST) majority of cases, that
> operation is dead in the water. So... It makes no sense to catch an
> exception anywhere inside that operation. It makes sense to clean up,
> get out and inform the user. So for example, a command-line utility
> will only catch in main(). Some kind of a server will catch on some
> request-processing boundary (e.g. in order to (try to) produce
> "request failed because: e.what()" response). And so on.
>
>> such a exception is a condition that you can not
>> recover except in following cases
>> 1. bad_allocation (Although handling this may also be a very difficult,
>> you have to employ things like reserving memory for such condition. May
>> be in few cases you can recover.)
>
> You can find many elaborate and heated discussions about catching
> bad_alloc on this newsgroup. ;-)
>
>> 2. vector length error
>> We should not try to catch other exceptions (using catch). When such
>> exception occur, default behavior (terminate) will take place and
>> program will dump core.
>
> I don't agree with that (see above). Exceptions are not (necessarily)
> about terminating the process. Almost always, they are about getting
> out, cleanning up, and informing the user about the error. IOW, I
> don't like dumping core. That's not "informing the user about the
> error". Dumping core is "informing the developer about the error".
> That's two different things - informing the user is about things that
> went wrong at runtime; informing the developer is about bugs in code.
>
> Goran.
>
> Yes, however, "will dump core" is system specific. You probably should
> have a giant try/catch in your main.
I am little confused now, If I sum up, you are saying, **almost all** 
the exceptions thrown by standard library are non recoverable so there 
is no use of catching them (looks scary). Programmer's are helpless when 
standard library throws exception (assuming they have checked all the 
error code but still software is rarely 100% correct)

If there are some exceptions that may be recoverable, would not it be 
good to list them down (catch all by ... will not help much) so that 
programmers can catch them and try to recover (if possible).

As far as the user defined exception are considered,you add **most of** 
them in the hope that software will recover from the exception 
condition, so not catching any exception is probably not a good idea.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

C++ standard library and exceptions ittium <ittium@gmail.com> - 2011-12-08 12:17 +0530
  Re: C++ standard library and exceptions ittium <ittium@gmail.com> - 2011-12-08 12:22 +0530
  Re: C++ standard library and exceptions Goran <goran.pusic@gmail.com> - 2011-12-08 01:02 -0800
    Re: C++ standard library and exceptions ittium <ittium@gmail.com> - 2011-12-08 16:35 +0530
      Re: C++ standard library and exceptions Goran <goran.pusic@gmail.com> - 2011-12-08 05:08 -0800
        Re: C++ standard library and exceptions ittium <ittium@gmail.com> - 2011-12-10 13:46 +0530
          Re: C++ standard library and exceptions "io_x" <a@b.c.invalid> - 2011-12-11 05:43 +0100
            Re: C++ standard library and exceptions "io_x" <a@b.c.invalid> - 2011-12-12 03:21 +0100
            Re: C++ standard library and exceptions André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-12-12 11:15 +0100
              Re: C++ standard library and exceptions Nobody <nobody@nowhere.com> - 2011-12-12 12:59 +0000
              Re: C++ standard library and exceptions Kaz Kylheku <kaz@kylheku.com> - 2011-12-12 17:28 +0000
                Re: C++ standard library and exceptions Paavo Helde <myfirstname@osa.pri.ee> - 2011-12-12 12:42 -0600
                Re: C++ standard library and exceptions Joshua Maurice <joshuamaurice@gmail.com> - 2011-12-12 14:18 -0800
                Re: C++ standard library and exceptions Sektor van Skijlen <ethouris@gmail.com> - 2011-12-19 02:38 -0800
                Re: C++ standard library and exceptions 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 03:52 -0800
              Re: C++ standard library and exceptions "io_x" <a@b.c.invalid> - 2011-12-13 09:16 +0100
              Re: C++ standard library and exceptions "io_x" <a@b.c.invalid> - 2011-12-13 09:17 +0100
                Re: C++ standard library and exceptions "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> - 2011-12-15 12:14 +0100
                Re: C++ standard library and exceptions Joshua Maurice <joshuamaurice@gmail.com> - 2011-12-15 15:50 -0800
                Re: C++ standard library and exceptions hanukas <jukka@liimatta.org> - 2011-12-17 21:57 -0800
                Re: C++ standard library and exceptions "io_x" <a@b.c.invalid> - 2011-12-19 04:02 +0100
                Re: C++ standard library and exceptions Joshua Maurice <joshuamaurice@gmail.com> - 2011-12-19 01:32 -0800
                Re: C++ standard library and exceptions Tobias Müller <troplin@bluewin.ch> - 2011-12-19 07:14 +0000
                Re: C++ standard library and exceptions Joshua Maurice <joshuamaurice@gmail.com> - 2011-12-19 01:29 -0800

csiph-web