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