Boost logo

Boost :

From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2002-06-20 13:05:58

"Hendrik Schober" <boost_at_[hidden]> wrote in message
> "Ted Byers" <r.ted.byers_at_[hidden]> wrote:
> > [...]
> > So then, something like my traceable exceptions may work for you, if
> > 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

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) {
  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.

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
> > (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
> > 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
> 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?



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