Does anyone have an opinion as to which of the std::exception derivatives is
most suited from deriving file I/O exceptions from? I know I can use just
about anything for an exception, but I really believe it's best to derive
from std::exception, or from its derivatives.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

* Steven T. Hatton:[color=blue]
> Does anyone have an opinion as to which of the std::exception derivatives is
> most suited from deriving file I/O exceptions from?[/color]

std::runtime_error

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

Alf P. Steinbach wrote:
[color=blue]
> * Steven T. Hatton:[color=green]
>> Does anyone have an opinion as to which of the std::exception derivatives
>> is most suited from deriving file I/O exceptions from?[/color]
>
> std::runtime_error[/color]

'std::ios_base::failure' could also be a reasonable candidate. This
class does, however, not derive from 'std::runtime_error' but only
from 'std::exception'.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

On Tue, 26 Jul 2005 11:57:14 +0200, Dietmar Kuehl
<dietmar_kuehl@yahoo.com> wrote:
[color=blue][color=green]
>> * Steven T. Hatton:[color=darkred]
>>> Does anyone have an opinion as to which of the std::exception derivatives
>>> is most suited from deriving file I/O exceptions from?[/color]
>>[/color]
>'std::ios_base::failure' could also be a reasonable candidate.[/color]

I disagree. Presently, class failure is thrown by the library to
indicate some combination of state bits have been set. Code that
catches exceptions of this type will be expecting the exception to
indicate this condition, and almost certainly will be broken by this
change.

Furthermore, there is no particularly compelling reason to derive from
this class, as its common meaning is not applicable to a general I/O
error, and thus deriving from this class adds no additional meaning
over simply deriving from std::exception.

The general guideline is to use one of the specific <stdexcept>
exceptions if they fit, otherwise use std::runtime_error for runtime
exceptional conditions (non-bugs), and std::logic_error for bug
conditions.

Arguably, for the latter class of "logic errors," it is better to
simply use assert() or similar, instead of (or in addition to,
depending) throwing an exception.


Aaron W. LaFramboise