[boost] Re: Re: improved assertions?

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