Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: ittium Newsgroups: comp.lang.c++ Subject: Re: C++ standard library and exceptions Date: Sat, 10 Dec 2011 13:46:05 +0530 Organization: A noiseless patient Spider Lines: 120 Message-ID: <4EE31545.3060802@gmail.com> References: <5230ac9e-7a6e-41c4-ba3e-1a8f37e9c9c0@d10g2000vbk.googlegroups.com> <4EE09A0D.2020602@gmail.com> <7532cea1-40db-406c-b396-fc3a63e5df0b@m10g2000vbc.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="ocrLSPAZlpBoCGs4SbY0Yg"; logging-data="25194"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+evagRjF97mVviF6BSfNq0" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 In-Reply-To: <7532cea1-40db-406c-b396-fc3a63e5df0b@m10g2000vbc.googlegroups.com> Cancel-Lock: sha1:5ugnGNnoYAjWIS0+Z8ZHFr6wDFQ= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:12283 On 08-12-2011 PM 06:38, Goran wrote: > On Dec 8, 12:05 pm, ittium wrote: >> On 12/8/2011 2:32 PM, Goran wrote: >> >> >> >> >> >> >> >> >> >>> On Dec 8, 7:47 am, 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. >> >>> 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.