On Thu, Mar 18, 2010 at 11:40:40AM -0400, Martin Cracauer wrote:
> > This is the reason why coding standards for systems with very high uptime 
> > requirements often disallow throwing exceptions.  This can extend to 
> > disallowing use of libraries that throw (or taking pains to configure libs 
> > so that they do not).
> Wouldn't that mean "don't let exceptions escape out of the library"?
> Not that I like either.
> In my mind, not using exceptions is almost a guarantee that there are
> resource leaks.  The only reason why this can halfway work today is
> that we have humongous amounts of virtual memory and can have
> thousands of file descriptions.

Heh, and using exceptions is also a guarantee that there are resouce
leaks unless the programmer is well disciplined with RAII, has
garbage collection (which only helps with memory resouces), or
reference counted smart pointers.  And even then they have to have
designed well enough not to forget that they have some collection
at top level or some global singleton that never releases a reference
to some huge tree of objects.  Too often it seems enough to say
only, "there are resource leaks."  I guess you folks are probably
reading better code than I am.  Still, tell me you haven't talked
to people who think it's perfectly normal acceptable practice to
run servers with a wrapper of some kind that kills them and restarts
them periodically.

But for safety critical projects, the no rtti, no exceptions rule
is pretty common isn't it?  Not sure if it's justified or not, but
very common from what I hear.  Something to do with code verification,
provability?  Not that that gives any lessons for application code
in other domains, necessarily.

Mike Small

Boston-pm mailing list

Reply via email to