When to use exceptions

[kelvSYC]

What I want to do is to read a 32-bit unsigned integer (let's call that
u32) in little-endian form from an fstream. Would it be better if my
function went like this:

// returns false if an error occurs reading the value
bool read(std::fstre am& stream, u32& value);

or this:

u32 read(std::fstre am& stream) throw(FileReadi ngException);

In general, what are some good guidelines for when something like the
first is preferred over something like the second, and vice-versa?

--
I am only a mirage.

[Rolf Magnus]

Niels Dybdahl wrote:

> I prefer to throw when an error occurs. This ensures me that the execution > of the calling function stops. Without throwing I might forget handling
> the error condition and such errors are hard to find during test.
However, if the calling code needs to know exactly where the reading
failed, it leads to excessive typing:

struct somestruct
{
long a;
long b;
long c;
};

//...

somestruct s;
try
{
s.a = read(stream);
}
catch (FileReadingExc eption& ex)
{
//... whatever
return; // or throw or whatever
}

try
{
s.b = read(stream);
}
catch (FileReadingExc eption& ex)
{
//... whatever
return; // or throw or whatever
}

try
{
s.c = read(stream);
}
catch (FileReadingExc eption& ex)
{
//... whatever
return; // or throw or whatever
}

//...

No. You can just do:

s.a = read(stream);

s.b = read(stream);

s.c = read(stream);

And how do I know whether s.c really contains a value read from the file?
No error checking code means that there is much less error checking code
to test.
And it leads to programs that print messages like "There was some error."
without letting the user know what the exact error actually was, because
that information got lost due to the missing error checking code.
How often do you make systematic test of your error checking code
?

You mean, you don't test how your program reacts to various errors in the
input data?

[Niels Dybdahl]

> > No. You can just do:

s.a = read(stream);

s.b = read(stream);

s.c = read(stream);
And how do I know whether s.c really contains a value read from the file?

It does. If an error occurred, the execution is breaked by an exception.

No error checking code means that there is much less error checking code
to test.

And it leads to programs that print messages like "There was some error."
without letting the user know what the exact error actually was, because
that information got lost due to the missing error checking code.

How often do you make systematic test of your error checking code
?

You mean, you don't test how your program reacts to various errors in the
input data?

No I do not mean that. I mean: do you go through your sourcecode to locate
all your error checking code and create test cases so that each error
checking code is tested for correct behaviour ? It is not nice to send out
an application where numerous code lines have never been executed.

Niels Dybdahl

[Rolf Magnus]

Niels Dybdahl wrote:

> No. You can just do:
>
> s.a = read(stream);
>
> s.b = read(stream);
>
> s.c = read(stream);
And how do I know whether s.c really contains a value read from the file?

It does. If an error occurred, the execution is breaked by an exception.

Ok, bad example. What about s.b then? If an exception during reading s.c is
thrown, s.b contains a valid value, if an exception is thrown earlier, it
doesn't.

> No error checking code means that there is much less error checking
> code to test.

And it leads to programs that print messages like "There was some error."
without letting the user know what the exact error actually was, because
that information got lost due to the missing error checking code.

> How often do you make systematic test of your error checking code
> ?

You mean, you don't test how your program reacts to various errors in the
input data?

No I do not mean that. I mean: do you go through your sourcecode to locate
all your error checking code and create test cases so that each error
checking code is tested for correct behaviour ?

No.
It is not nice to send out an application where numerous code lines have
never been executed.

And you think it's better to leave that code out completely?

[Niels Dybdahl]

> >> > No. You can just do:

>
> s.a = read(stream);
>
> s.b = read(stream);
>
> s.c = read(stream);

And how do I know whether s.c really contains a value read from the

file?
It does. If an error occurred, the execution is breaked by an exception.
Ok, bad example. What about s.b then? If an exception during reading s.c

is thrown, s.b contains a valid value, if an exception is thrown earlier, it
doesn't.

So if an exception occurs, you have to treat all values gained in this
functionality as invalid. Code designed on returned error values have exact
the same problem. For local variables it is not a problem as they are
automatically destructed and removed. For global variables you will always
have the problem: What to do if the structure is only partly created due to
an error ?

No I do not mean that. I mean: do you go through your sourcecode to locate all your error checking code and create test cases so that each error
checking code is tested for correct behaviour ?

No.

It is not nice to send out an application where numerous code lines have
never been executed.

And you think it's better to leave that code out completely?

If the error still can be handled, as it can with exceptions, then yes. Deep
into the "read" function there are still error checking code that can throw
and I hope that the author of that function has tested that. At a high level
I would have a try/catch block that catches all errors and reports the
errors to the operator or to a log. I might have a few try/catch blocks for
cleaning up, but I try to avoid that as much as possible and use destructors
instead.
This has two advantages: Less untested code and my code consists of less
error handling, so that is easier to read and maintain.

Niels Dybdahl