----- Original Message ----- From: "Peter Dimov" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Thursday, November 14, 2002 1:32 PM Subject: Re: [boost] Proposed Boost Assert -- once again
> - there is no explicit support for throwing exceptions, and no standard > exception class is defined. (Although it is trivial to define a handler that > throws.) This is intentional. I don't believe that we, at Boost, want to > encourage this particular programming practice (assertions that throw.) > AFAIK, the differences between abort and throw are two-fold. On one hand, there are platform/compiler-dependent differences. Some enviroments (mostly Unix-like) don't allow you to get context information at the point of the throw, but, OTOH, supply a core-dump in the case of abort(). On these enviroments, abort() is clearly superior. Other enviroments (Windows) do allow you to get context information at the point of the throw and do not supply a *textual* core-dump for post-morten debugging (although you can use JIT). On this enviroment, throw is clearly superior. On the other hand, there are application level differences. Some applications find much better to abort *just the current task* in case of a library failure. In many cases, those failures are far from catastrophic and the application can keep running normally without much trouble. In these applications, even during a debug session it might be useful to let the application keep running because the programmer might need do something else before finally aborting (such as testing other tasks or saving documents). This is a typical scenario with event driven applications with builtin fault tolerance. There are also critical applications which simply *cannot* just abort in case of a failure. Therefore, I conclude that there is not a unique preferable way to deal with assertions. On the application-level, user needs are so varied that the best we can do is to provide a hook so that the user can do whatever she needs to do. This role is well played by "assertion_failed()". On the library-level, the best choice is IMO given by the target platform. For example, if you are targeting Borland on Windows, like me, then abort() is a very bad choice since it leaves no information whatsoever. An exception, on the other hand, is caught by the compiler right at the throw and I can see all I need to spot the problem. But on most Unix-like systems, the situation is exactly the other way around: abort() gives you a core-dump while an exception unwinds the stack *before* you get a chance to see what happened. Therefore, I think that a good choice would be to have a default assertion behaviour based on the target platform. How to supply a target-dependent default definition and at the same time allow the user to override it easely I'm not sure. It appears that Kevin Van Horn's proposal might suite better my criteria. > - there is no BOOST_ASSERT_MSG. I don't have a strong opinion here. As the > main purpose of BOOST_ASSERT is to replace the standard assert, and since > the file/line/function supply enough information, I haven't provided a > BOOST_ASSERT_MSG macro, but I'm not strongly opposed to having one, either. > I've found additional textual information quite useful in many cases, so I'd vote for including the _MSG variant. Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
