Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++ standard library and exceptions

Reply
Thread Tools

C++ standard library and exceptions

 
 
ittium
Guest
Posts: n/a
 
      12-08-2011
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. I was wondering what is the best way to
find out the list of exception a standard library routine can throw. I
am actually looking for **some kind** of standard man pages, that talks
about exceptions apart from method signatures and return values.
thanks
Ittium
 
Reply With Quote
 
 
 
 
ittium
Guest
Posts: n/a
 
      12-08-2011
On 12/8/2011 12:17 PM, ittium 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. I was wondering what is the best way to
> find out the list of exception a standard library routine can throw. I
> am actually looking for **some kind** of standard man pages, that talks
> about exceptions apart from method signatures and return values.
> thanks
> Ittium


PS: I am aware of the document
http://www2.research.att.com/~bs/3rd_safe.pdf
I am actually looking for some online resource that I can refer before
using any standard library routine (like we do for system call error codes)
 
Reply With Quote
 
 
 
 
Goran
Guest
Posts: n/a
 
      12-08-2011
On Dec 8, 7:47*am, ittium <(E-Mail Removed)> 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.
 
Reply With Quote
 
ittium
Guest
Posts: n/a
 
      12-08-2011
On 12/8/2011 2:32 PM, Goran wrote:
> On Dec 8, 7:47 am, ittium<(E-Mail Removed)> 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, 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.)
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.

Ittium



 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      12-08-2011
On Dec 8, 12:05*pm, ittium <(E-Mail Removed)> wrote:
> On 12/8/2011 2:32 PM, Goran wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 8, 7:47 am, ittium<(E-Mail Removed)> *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.
 
Reply With Quote
 
ittium
Guest
Posts: n/a
 
      12-10-2011
On 08-12-2011 PM 06:38, Goran wrote:
> On Dec 8, 12:05 pm, ittium<(E-Mail Removed)> wrote:
>> On 12/8/2011 2:32 PM, Goran wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Dec 8, 7:47 am, ittium<(E-Mail Removed)> 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.


 
Reply With Quote
 
André Gillibert
Guest
Posts: n/a
 
      12-12-2011
"io_x" <(E-Mail Removed)> wrote:
> +comp.lang.c
> "ittium" <(E-Mail Removed)> ha scritto nel messaggio
> news:(E-Mail Removed)...
> > On 08-12-2011 PM 06:38, Goran wrote:
> >> On Dec 8, 12:05 pm, ittium<(E-Mail Removed)> wrote:
> >>> On 12/8/2011 2:32 PM, Goran wrote:
> >>>

>
> i actualy think:
> all exceptions in C or C++ library, or whatsover library,
> but division by 0, has to be turned off
>
> all beahavour of seg fault or "abort()" in C or C++ library
> or in each library, has to be minimized to 0
>
> for this i say all function has to return a possible
> error code
> all function in C has no error code are badly thinked
>
> this is valid too for API library OS too
>
>
>


Followup-To: comp.lang.c++

Do you mean that the behavior of segfault should be defined as throwing
a standard C++ exception?

Well-defined programs cannot have any segfault... Any program having a
segfault is in inconsistent state. Important data may have been
damaged, and there is no guarantee of any sort of recovery.

For the sake of security and data integrity, a good system detecting
such an error, should kill/abort/terminate the program immediately.

--
André Gillibert
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      12-12-2011
On Mon, 12 Dec 2011 11:15:24 +0100, André Gillibert wrote:

> Well-defined programs cannot have any segfault... Any program having a
> segfault is in inconsistent state. Important data may have been
> damaged, and there is no guarantee of any sort of recovery.
>
> For the sake of security and data integrity, a good system detecting
> such an error, should kill/abort/terminate the program immediately.


That's a slight over-generalisation. There are situations where it's
possible to handle a segfault. But such cases aren't the norm, and
handling them is complex and requires non-portable code. They certainly
shouldn't be converted to exceptions automatically.

 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      12-12-2011
On 2011-12-12, André Gillibert <(E-Mail Removed)> wrote:
> "io_x" <(E-Mail Removed)> wrote:
>> +comp.lang.c
>> "ittium" <(E-Mail Removed)> ha scritto nel messaggio
>> news:(E-Mail Removed)...
>> > On 08-12-2011 PM 06:38, Goran wrote:
>> >> On Dec 8, 12:05 pm, ittium<(E-Mail Removed)> wrote:
>> >>> On 12/8/2011 2:32 PM, Goran wrote:
>> >>>

>>
>> i actualy think:
>> all exceptions in C or C++ library, or whatsover library,
>> but division by 0, has to be turned off
>>
>> all beahavour of seg fault or "abort()" in C or C++ library
>> or in each library, has to be minimized to 0
>>
>> for this i say all function has to return a possible
>> error code
>> all function in C has no error code are badly thinked
>>
>> this is valid too for API library OS too
>>
>>
>>

>
> Followup-To: comp.lang.c++
>
> Do you mean that the behavior of segfault should be defined as throwing
> a standard C++ exception?
>
> Well-defined programs cannot have any segfault... Any program having a
> segfault is in inconsistent state. Important data may have been
> damaged, and there is no guarantee of any sort of recovery.


Sorry, that's a ridiculous assertion. Catching segfaults is a useful
software technique that can be used to do cool things. A software emulator for
a CPU can catch a segfault to detect that writes are taking place to simulated
I/O space. Garbage collectors can use segfaults. Some Lisp implementations
catch SIGSEGV as part of their garbage collector implementation. For instance
CLISP has a "libsigsegv" library for handling access violations and fixing them
up:

http://libsigsegv.sourceforge.net/

> For the sake of security and data integrity, a good system detecting
> such an error, should kill/abort/terminate the program immediately.


That is a silly view. Detecting the error already provides security and
integrity.

In all advanced CPU architectures, exceptions store enough information so that
the handler can recover by fixing the situation and resuming the program (if
that makes sense).

Terminating the program isn't the only possibility.

Since architectures provide the capability, it means that higher level
languages which do not map the capability are crippled with respect to machine
language.

I.e. you have some better exception handling features at the instruction set
level than you do in C++.
 
Reply With Quote
 
Joshua Maurice
Guest
Posts: n/a
 
      12-12-2011
On Dec 12, 10:42*am, Paavo Helde <(E-Mail Removed)> wrote:
> The main problem with segfaults is that they are not guaranteed. A memory
> page which was not present in some run may be present in another run,
> maybe because of the overall load of the computer has changed, or the
> program itself altered slightly. Thus it is not guaranteed that
> dereferencing an invalid pointer causes a segfault. If it does not, the
> program may easily silently misbehave, which is much worse by far. Ergo,
> dereferencing an invalid pointer is a bug in the program which must be
> fixed.


Portably speaking, there is no such thing as a segfault. On some
systems which define "segfault", you can guarantee that a segfault
will occur in some situations. The specific situation in mind is when
you dereference a null pointer. Again entirely non-portable, but
sometimes incredibly useful.

> If some (part of the) program as the garbage collector has been carefully
> coded to not misbehave when accessing potentially invalid memory
> locations, then yes it is possible to work with segfaults. I suspect such
> garbage collectors will have non-deterministic behavior by themselves and
> will not always release all memory blocks they could (erring on the safe
> side). This does not mean that relying on segfaults is a good idea for an
> ordinary program.


A much simpler example to fathom is Sun's JVM. It is very carefully
coded to catch seg faults, and on seg fault see if it just tried to
dereference a pointer, specifically a user Java reference, and then
check if that Java reference / pointer is null. This is an
implementation of Java that basically has 0 overhead for null pointer
checking, specifically guaranteeing that a Java exception will be
thrown when a Java null reference is dereferenced.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: C++ standard library and exceptions André Gillibert C Programming 4 12-19-2011 09:32 AM
add pexpect to the standard library, standard "install" mechanism. funkyj Python 5 01-20-2006 08:35 PM
How standard is the standard library? steve.leach Python 1 04-18-2005 04:07 PM
Re: Possible additions to the standard library? (WAS: Aboutstandard library improvement) Daniel Bickett Python 0 02-04-2005 11:22 AM
Re: Possible additions to the standard library? (WAS: Aboutstandard library improvement) Fredrik Lundh Python 0 02-04-2005 07:34 AM



Advertisments