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.

[Alf P. Steinbach]

* 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);
Given only these two to choose from:

the first and only the first.

But also provide a throwing version like the second but without exception
specification.

In general, what are some good guidelines for when something like the
first is preferred over something like the second

Always. Exception specifications are very impractical and misleading in
C++. There are only a few forms that are acceptable, in certain contexts.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[kelvSYC]

> > // 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);

Given only these two to choose from:

the first and only the first.

But also provide a throwing version like the second but without exception
specification.

So a comprimise like so:

// throws exception if an error occurs reading the value, but is not
// specified in the prototype
u32 read(std::fstre am& stream);

would be acceptable C++ style then?

--
I am only a mirage.

[Alf P. Steinbach]

* kelvSYC:

// 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);

Given only these two to choose from:

the first and only the first.

But also provide a throwing version like the second but without exception
specification.

So a comprimise like so:

// throws exception if an error occurs reading the value, but is not
// specified in the prototype
u32 read(std::fstre am& stream);

would be acceptable C++ style then?

1. What if you need i32 result, double result, and so forth?

2. What if you'd like to use this for a stream that's not an fstream?

3. The earlier quandary seems to indicate a non-throwing version can
come in handy, and there's no need to exclude it.

So perhaps

template< typename T >
void throwIf0( T nonzero, char const diagnostic[] )
{
if( !nonzero ){ throw std::runtime_er ror( diagnostic ); }
}

bool readBinary( std::istream& stream, u32& result ){ ... }

u32 u32FromBinary( std::istream& stream )
{
u32 result;
throwIf0( read( stream, result ), "my useful diagnostic" );
return result;
}

For text I'd just read text strings and convert them to whatever
they represent, because such functions are much cleaner and more
reusable, and because stream based text-to-other conversion is not
well-defined in C++ (the interface is there, the definition not).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Niels Dybdahl]

> 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);

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.

Niels Dybdahl

[David]

On Mon, 6 Jun 2005 07:22:36 UTC, "Niels Dybdahl" <nd*@esko-graphics.com>
wrote:

<snip>

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.

Niels Dybdahl

My preference, as the designer and developer of a function, is to provide
adequate documentation about the behavior and abilities of said function.
As the user of functions that others have developed, I want to see such
documentation as well.

My reasoning is that at any location in a given fragment of code, an
error may occur. Some errors are more likely than others. Exception
based error reporting enforces the user to wrap all code levels with
appropriate exception handling code. This must be done often enough
that the user can actually find and correct the cause of an error
when it occurs. For any given level of functionality, there are many
possible errors to report -- whether they may be from exceptions or
other known sources.

Given a well documented interface, the user can then decide what
is an appropriate use for their needs. This includes handling
unexpected conditions.

Users need to handle errors at a reasonable level. Your preference
to use an exception to report "an expected file error" may be appropriate
for one developer and not another.

My preference for using exceptions is to use them very sparingly
and with good cause. Before exceptions were common, return codes
and other methods were commonplace. The user had to decide at what level
to check for these unexpected conditions. Exceptions give us a different
method of reporting errors. Now users are faced with handling both
methods all of the time. Your code could be quite complicated for
handling information (expected and unexpected behavior) for any non-trivial
function. When designing interfaces, please make it easy to understand
what the expected behavior is. I should be able to use nearly all
interfaces by reading just the interface documentation (.h and other files).
You should make it easy for the user to handle all errors and behaviors
appropriately. That has different meanings for different environments.
So, consider your user base when designing an interface.

Your suggestion that the interface provide both non-exception and
exception based functions is a good one. However, when that function
is non-trivial, you may find that writing both versions at a level that
can handle all errors appropriately may be a daunting task. The two
functions may not even look the same. Keeping them in-sync could be
difficult.

David

[Rolf Magnus]

Niels Dybdahl wrote:

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);

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
}

//...

[Julián Albo]

kelvSYC wrote:

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

IMO that depends of the file format. If, for example, you are reading until
eof, the first way is best. If the format is fixed, and you know how much
data is in the file and a failure to read means that the file is corrupt or
unreadable, the second way allows cleaner code.

--
Salu2

[Julián Albo]

Rolf Magnus wrote:

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
}

You can do something like that:

void readsome ( ..... , StatReadSome & stat)
{
.....
stat= ReadSomeNothing ;
s.a= read (stream);
stat= ReadSome_a;
s.b= read (stream);
stat= ReadSome_b;
....
}

--
Salu2

[Niels Dybdahl]

> > 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);

No error checking code means that there is much less error checking code to
test. How often do you make systematic test of your error checking code ?

Niels Dybdahl