"John Maddock" <john@johnmaddock.co.uk> wrote in message news:012c01c69900$308fd4a0$b10d1452@fuji...
Jeff Garland wrote:
Well, you're assuming that report will be called in a destructor. If it isn't and some sort of exception is thrown then the application can't handle it because you've eaten it. You could always have 2 versions:
void cpu_time_reporter::report_no_exceptions() throws() void cpu_time_reporter::report()
Or how about:
void cpu_time_reporter::report(std::nothrow_t)throw() ?
It's situations like this that we have std::nothrow for isn't it?
Just a thought.
I'm going to refine and apply the error handling guidelines I posted a while ago to cpu_timer/cpu_timer_reporter. Your post gives me an idea for a further refinement: There are three useful behaviors, depending on the app, for functions that may encounter an operating system API error: 1. Throw an exception. 2. Report the error by setting a error_code & argument to the error code. 3. Ignore the error. I suggest folding 2 and 3 into a single case by just proving (2), since the caller is free to ignore whatever the error_code & gets set to, and that effectively is the same as (3). It is a bit inconvenient to use, because the users has to declare an otherwise unneeded variable as the target for returning the error_code. But suppose we provided: namespace boost { extern error_code nothrow; } Then the user can get the effect of (3) by writing: boost::system::cpu_time_reporter tr( boost::nothrow ); --Beman