Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!dedekind.zen.co.uk!zen.net.uk!hamilton.zen.co.uk!reader01.nrc01.news.zen.net.uk.POSTED!not-for-mail From: Nobody Subject: Re: Error codes vs. exceptions Date: Thu, 31 May 2012 05:04:36 +0100 User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: Newsgroups: comp.programming,comp.lang.c++ References: <4f571f71-55ca-4922-b81b-31f954cac855@kw17g2000pbb.googlegroups.com> <4fc6db28$0$561$c3e8da3$4db35a27@news.astraweb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lines: 32 Organization: Zen Internet NNTP-Posting-Host: 42451a38.news.zen.co.uk X-Trace: DXC=>^:\JCS7iRIAjCo>?LEUROa0UP_O8AJoL=dR0\ckLKG@WeZ<[7LZNRFRQWS0lXYZ7LM2Z^cWRFGAK5`:FiD8jFlI X-Complaints-To: abuse@zen.co.uk Xref: csiph.com comp.programming:1678 comp.lang.c++:16446 On Wed, 30 May 2012 22:44:56 -0400, Pavel wrote: > I know you have already received lots of advice; but I think they omit an > important factor, namely whether you are writing a library. In my > experience, I found it quite annoying when the API of a library I use can > throw. Catching all possible exceptions after every call is even more > disrupting than processing return codes and letting them through often > creates a mess with multiple error processing policies coming from > different libraries or from my application and library or libraries it > uses. That's a non-issue for exceptions which should never need to be thrown in the first place, e.g. an invalid argument value. If you don't want to have to catch such exceptions, don't cause them to be thrown. Even where it is an issue, any API design involves trade-offs. Having every function return a status indication may be more efficient for code which always handles failures directly in the caller. OTOH, it imposes a significant burden on code which would otherwise just allow an exception to propagate up to a higher level. It's impossible to provide a hard-and-fast definition of which conditions are "exceptional", particularly for a library. OTOH, it's equally impossible to provide a hard-and-fast rule regarding the side on which to err. Treating any condition which might conceivably be caught in the immediate caller as non-exceptional is likely to result in a rather inconvenient API for the majority of code. I mean, the STL *could* have a given every container type a "bad bit" (in the same vein as iostream) to indicate allocation failure, but I'm rather glad it didn't.