Boost logo

Boost :

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

"Hendrik Schober" <boost_at_[hidden]> wrote in message
> "Ted Byers" <r.ted.byers_at_[hidden]> wrote:
> > [...]
> > However, my base exception also allows for the user (the programmers'
> > code) to set a custom message for each place where an exception can be
> > thrown. so you could have something like:
> >
> > void f(void) {
> > static std::string msg;
> > static const std::string msgA("Here");
> > msg = msgA;
> > bool rcA = Herefunction();
> > ...
> > static const std::string msgB("There");
> > bool rcB = ThereFunction();
> > ...
> > };
> >
> > 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()
> {
> doSomething()
> doMore();
> doEvenMore();
> doYetMore();
> }
> 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
> > 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?



Boost list run by bdawes at, gregod at, cpdaniel at, john at