[boost] Re: Re: improved assertions?

From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2002-06-21 07:04:43

"Hendrik Schober" <boost_at_[hidden]> wrote in message
news:009f01c21917$33860ac0$b100000a_at_schobi...
> "Ted Byers" <r.ted.byers_at_[hidden]> wrote:
> > [...]
> > However, my base exception also allows for the user (the programmers'
using
> > code) to set a custom message for each place where an exception can be
> > thrown.  so you could have something like:
> >
> > void f(void) {
> >   ERROR_STACKTRACE_BEGIN
> >   static std::string msg;
> >   static const std::string msgA("Here");
> >   msg = msgA;
> >   bool rcA = Herefunction();
> > ...
> >   static const std::string msgB("There");
> >   bool rcB = ThereFunction();
> > ...
> >   ERROR_STACKTRACE_END
> > };
> >
> > This allows a finer granularity in knowing where the exception came from
> > without having to give each statement its own try/catch block.
>
>   I don't see the need for this. You can always put
>   more of these macros into your code, if you want
>   better granularity:
>
>     void f()
>     {
>       ERROR_STACKTRACE_BEGIN {
>         doSomething()
>         ERROR_STACKTRACE_BEGIN {
>           doMore();
>         } ERROR_STACKTRACE_END
>         ERROR_STACKTRACE_BEGIN {
>           doEvenMore();
>         } ERROR_STACKTRACE_END
>           doYetMore();
>       } ERROR_STACKTRACE_END
>     }
>
>   This gets you rid of the string/resource problem.
>
No, it doesn't.

First, I had recognised your solution, as well as one in which the try/catch
blocks would not have been nested (except for nesting the try/exccept blocks
within try catch blocks, for handling MS structured exceptions, if that is
required).  But I had wanted to avoid that.

Second, the strings I am using are static constant strings, except for the
one used directly by my macros, so if I understand things correctly, they'll
be already constructed in the data segment of the program once the program
is running: they are, after all, just string literals wrapped in an
std::string, and they're constant static variables within the functions
they're used in.  If this is correct, to have this usage not throw, all I
have to focus on the default and copy constructors, and assignment operator.
But using more try/catch blocks does not get rid of the string problem
because most of the data members in my traceable exception classes are
std::string.  Thus, I have to alter my use of them, or replace them, so that
default and copy construction, and assignment, do not throw anyway,
regardless of whether I use multiple try/catch blocks or my message strings.

> > [...]
> > So then, when the CPU raises a signal that a floating point error has
> > occured, we have to wait for the OS (Windows) to convert it into an OS
> > exception we can then catch?  Or have I misunderstood what is happening
when
> > an invalid floating point exception is produced by the OS?
>
>   SEHs are a MS thing. The standard way to do this is signals.
>   But within a signal handler you can't do much except setting
>   an (atomic) flag.
>   I don't know much about the details of SEH, but I think these
>   exceptions are synchronous. But I really don't knwo that.
>
I was wondering aloud here about "how did they do that?"  Presumably the OS
has to use a signal handler to get the hardware exceptions, in order to be
able to throw a structured exception.  But if you can't do much but set an
atomic flag, how did they do it?  And if they can do it, why can't we?

Cheers,

Ted