Thread: To throw or not to throw

Originally Posted by phantomotap

Nope. I specifically said "However, we expect that we may be reading the last bits of the stream so `eofbit' is not an error.".

In that case, what point were you trying to make with that long winded post?
Why are you checking the badbit after getting an exception? The whole point of the exception is to deliever the bad news, and alleviate the need to call to bad(). What an awful hodgepodge.

Originally Posted by phantomotap

You did a fantastic job breaking the code!

You've forced the client to report an error (The `err' in `std::cerr' stands for "error".) even if the situation is actually normal from the client's perspective.

The client can't now treat the configuration file missing as a normal occurrence.

stderr was indeed create with errors in mind, but it's nowadays commonly used for any auxillary non-error output; *nix doesn't have stdaux or stdwarn.
So, it's fine to write to stderr but still return success to a caller.

If you are serious about "handling" exceptions internally with a log trace, what are you going to do if `getDefaultConfig' raises an exception?

As you know, loadConfigFileOrDefaults() would unwind then. But that's okay, because the caller expects (as the function is so name) configuration to be loaded from the file or defaults. There's nothing wrong with that, it's all well and expected.

Edit: Though, if getDefaultConfig can throw, it may be appropriate to call it before the warning is reported.

Why are you checking the badbit after getting an exception? The whole point of the exception is to deliever the bad news, and alleviate the need to call to bad().

o_O

You actually don't read your own comments.

The `std::ios' components allow you to specify which error states raise an exception.

In other words, the `std::ios' components "conditionally throw an exception" which is a "is a recipe for disaster" according to you.

If the `std::ios' components didn't "conditionally throw an exception", you would have to idiotically filter the exceptions or examine the return codes as my examples show to ignore the spurious `EOF' situation while still reporting other erros.

Only because the `std::ios' components "conditionally throw an exception", I do not need to idiotically filter irrelevant exceptions or examine return codes for problems I can't handle.

Code:

void DoSomething
(
    std::istream & f
)
{
    IOSState sRollback(f);
    sRollback.exceptions(badbit);
    int sValue;
    while(f >> sValue) // We allow the exception to
    {
        // We can use `sValue' as we need.
    }
    // We can do more stuff.
}

Thanks to the `std::ios' components "conditionally throw an exception" aspect, I'm only writing code for the situations I care about.

I am not required to "write the code for both approches".

You are simply spewing nonsense.

Soma

As you know, loadConfigFileOrDefaults() would unwind then. But that's okay, because the caller expects (as the function is so name) configuration to be loaded from the file or defaults. There's nothing wrong with that, it's all well and expected.

O_o

Exactly.

[Edit]
There is nothing wrong with swallowing the exception from `loadConfig' without forcing the trace on the client because "it's all well and expected" that `loadConfig' might fail.
[/Edit]

It's a solution is search of a problem.

o_O

The optional mechanism raising an exception can be a perfect answer to the "Should an interface return an error code or raise an exception?" question.

You aren't forced to do just one or the other; you can do both allowing the client to choose according to the situation.

Nor is one required to when using, for example, posix read(). It returns 0 on EOF, no option to make it an error. Yet, escalating it to an error if you so wish is very easy.

I didn't say that you would have to write code for both approaches.

You are the one responsible for posting that nonsense.

No "ios" equivalent needed (or wanted)!

Certainly.

I don't directly use the `std::ios' components or "POSIX" interfaces.

I'm not trying to force you.

I like to use simple solutions to solve simple problems.

Wonderful.

I like to use the simple solutions to any problem I face.

Happily, an optional mechanism raising an exception allows you to inspect your return code while I don't have to ........ about transforming a return code into an exception.

We both get to use our simple solutions without writing crappy boilerplate code.

Yay!

Soma

Most operating systems have a way of getting a backtrace. E.g., for windows.

Until then you're just going to have to do like everyone else does: use platform specific APIs and hide those behind an interface. Unless some platforms you're working on does not support getting backtraces via some API, this is the easiest method.