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 sma...@panix.com _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
