Please don't consider this a review of the Exception library. I am neither for nor against it. This is more of my gripe session so please forgive me. The exception library is like C++0x, "it is nothing that I asked and wished for but everything I didn't know that I needed". This is both bad, more like mildly disappointing cause of the 10+ year wait, and exceptionally good. My 3 wishes for C++ are standardized dll's, standardized reflection and standardized stack traces. The exception library touches on my 3rd wish/gripe. It is great that a filename can be associated with an exception thrown at a lower level that didn't know that information. Yet, the additional information is purely optional. There is no guarantee that the rethrower ever added the information. As such the final catcher will have to do a lot of tests to see if the information exists. However, it doesn't seem to do anything to get me one step closer of generating a stack trace when the exception is thrown or at least when the boost::exception is constructed. There are no callbacks/hooks to add this capability to everything that derives from boost::exception when the data is not optional. It is not good enough for such stack trace and potential other information to sometimes be there as it is information that should always be available. It is as specialized as my wish and maybe doesn't deserve the name boost::exception. Maybe it should be renamed to boost::map_exception, boost::tuple_exception, boost::additional_optional_information_exception or something similar and in the future an exception class that provides stack traces can be called boost::stacktrace_exception. Let's keep, reserve, the word boost::exception for the day when it handles most everyone basic exception needs; both sets of functionality. P.S. Add method "array<int> getStackTrace()" or "fillStackTrace(array<int>&)" which would provide the trace of the EIPs would go a long way. This could be an empty array when it couldn't be done as in inconsistent register based passing of parameters. It could be simple machine language stack tracing that can't handle inline functions or more complex that relies on internal symbol information, because some information is better than nothing. The EIPs could latter be reconciled using MAP files or .pdbs. The main thing is the pseudo-standard abstraction.