On Fri, Jun 10, 2011 at 08:29:58AM -0800, Robert Ramey wrote:
Lars Viklund wrote:
On Thu, Jun 09, 2011 at 10:25:51PM -0800, Robert Ramey wrote:
By "trap an exception", do you refer to some capability of breaking when any exception is thrown or just uncaught ones?
It is my custom when running my projects to set the IDE so it traps in the debugger any time an exception is thrown. Since I only throw and exception when I have an error, this only happens when I have a bug.
Other people operate according to different creeds. I know of and work in a SDK where the application routinely catches file_not_found exceptions many times during its startup phase, which I consider being well within its right to do. It might be beneficial to submit a feature request to your vendor for narrowing and filtering such things to your own code, as it can probably be a quite useful debugging asset to have when iterating on code.
Exceptions are part of normal C++ life, they do and will occur during the natural execution of programs, no matter what your philosophy on them are. If I configure the IDE to break whenever an exception is thrown and caught, I'd never get anywhere.
I don't know how to respond to this.
Please do not interpret my message as trying to insult you or the way you develop software. If you have a consistent philosophy on when exceptions are warranted, excellent for you. I'm just saying that there are use cases where exceptions are downright essential or are the only way to do something in a feasible way.
Does this have any effects that you want to avoid? Do you want someone to investigate why an exception is thrown in the first place?
How can just including a header invoke an exception - before main(..) is even called and not have it be a bug?
Here is a small test which you can use to demonstrate the problem
#include
int main(int argc, char * argv[]){ return 0; } Where is the bug in the above test program?
There is no bug in neither your code nor the Boost.Thread code. The library is very well operating within the standard, assuming that it throws and catches exceptions where allowed. The only reason you notice that implementation detail at all is that you've told your runtime environment to introspect the execution so intrusively. In closing words, I should re-iterate that I mean no offense by my response. I'm just making my standpoint clear and trying to extract any information on what the issue was with the library. As I interpreted it, it could be that you've found that it invoked undefined behaviour by utilizing exceptions too early in the processes, didn't catch the exceptions in all cases, or something of that kind. -- Lars Viklund | zao@acc.umu.se