From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2002-06-20 13:05:58
"Hendrik Schober" <boost_at_[hidden]> wrote in message
news:022301c21878$aeca7080$b100000a_at_schobi...
> "Ted Byers" <r.ted.byers_at_[hidden]> wrote:
> > [...]
> > So then, something like my traceable exceptions may work for you, if
you're
> > willing to add a couple automatic string variables and one macro at the
> > beginning of each function [...]
>
> Why that string? That's (approximately) how I do it:
>
Yes, I know, and for the __LINE__ and __FILE__ strings, I left them in the
macros.
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.
But here is one problem I haven't decided on how to resolve in this
situation (which is why I said that my prototype has a few warts I want to
resolve). std::string can throw. I want to replace it, or change how I am
using it, so that the code that produces the exception and eventually stores
it in a file can't throw. I know there are possibilities, but I haven't
quite figured this out.
>
> > Hopefully I will get a
> > simple example put together and sent to Schobi showing how I use this
RSN
> > (I'd be faster with this if I didn't have to earn a living ;-)).
>
> Yeah, it's easier for me to upload it, isn't it? <g>
>
Nope, I wasn't thinking of that. I was thinking of the time required to put
a useful example together.
I appreciate your help in making it available, but if I had my own website,
it would be there.
> > [...] Have you written signal
> > handlers that deal with the various sorts of hardware or OS error that
might
> > occur and need to be handled? If so, what do you think of the idea of
> > trapping these signals and converting them into exceptions (giving the
> > exception all the information you can collect at the point the signal is
> > raised), and then throwing and converting these into traceable
exceptions?
>
> There isn't much that you're allowed to do in a
> signal handler. Throwing exceptions isn't among
> that. (AFAIK, you might not even have a valid stack
> frame within a signal handler.)
>
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?
Cheers,
Ted