Re: [Boost-users] boost exception question when threadinglibrary header is included.

Subject: Re: [Boost-users] boost exception question when threadinglibrary header is included.
From: Lars Viklund (zao_at_[hidden])
Date: 2011-06-10 12:11:27

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 <boost/thread.hpp>
> >> 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_at_[hidden]