[bind10-dev] whether/when to use exceptions

[Christos Zoulas]

On Oct 8,  8:52pm, jinmei at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKE) wrote:
-- Subject: Re: whether/when to use exceptions

| At Thu, 8 Oct 2009 20:45:42 -0400,
| christos at zoulas.com (Christos Zoulas) wrote:
| 
| > | Resource leaks are certainly a common compliant against (C++)
| > | exceptions, and I guess "without smart pointers" is a key here.  Maybe
| > | I'm naive, but in my understanding many of resource leak problems with
| > | exceptions can be smartly avoided using RAII techniques (including the
| > | use of smart pointers).  If we decide to rely on exceptions relatively
| > | heavily, I guess we should equally heavily use RAII.
| > 
| > And then performance suffers [extra code for constructors and destructors
| > and then the try / catch]. And all of that complexity for what?
| 
| To me, for improving code readability/comprehensibility by separating
| exceptional cases and corresponding cleanups from the normal code
| logic.

[ examples deleted ]
 
| I guess Michael's motivation he explained in an earlier message is
| basically the same.
| 
| Whether or not we use our own exceptions heavily, we should also note
| that it's (very) difficult to make the code completely exception-free,
| especially if we want to use STL (and I think we do) because we should
| also expect a std::bad_alloc exception.  So, I suspect we'll need to
| have some try-catch anyway.

It depends what are your goals. The STL code is very uneven; some of it
is pretty good, but there are parts that are really bad (the hashtable
is a red-black tree internally, and the default string hashing function
is poor for example). It also does excessive allocations and de-allocations.

Strings are not great either... If you want a high performance application,
you'll probably want to avoid STL. If you don't care about burning CPU,
STL is fine.

The latest example was one someone @ work wrote a feed handler using STL
that used ~60% cpu, and when we ripped out all the STL code and used plain
c stuff, it used < 10%... Again this was an application where STL did
excessive allocation/deallocation and this really hurt performance.

christos