Re: Necessity of multi-level error propogation
On Mar 18, 1:08 am, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
On Mar 17, 5:22 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
On Mar 15, 8:49 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
I'm saying that every error should have a corresponding
exception, and every exception should represent some error.
In other words, you're defining exception as error, and
error as exception.
Those certainly are "other words," and they don't mean the
same thing at all. I think you know better.
I do, but you seem to be saying that one implies the other.
I'm saying that in my preferred design style, one does imply
the other. You keep reducing that to a tautology, which it is
not.
Maybe I just can't believe such a claim. If you use the general
meaning of error which I use (and find wide spread), then there
are errors that you cannot or don't want to handle with an
exception. As a radical example: the loss of power on the
mother board. If you say that all errors should be reported by
exceptions, either you're using the concept of "should be
reported by an exception" to define error, or you're introducing
some other constraint on the meaning, that you've not clarified.
Do you really mean, for example, that any hardware error (e.g.
parity error in memory) should be mapped to an exception? Do
you really mean that a blatent software error in the code (e.g.
a segment violation, under Unix), should be mapped to an
exception. Do you really mean *any* user error (e.g. under
Unix, the user accidentally gives the process id of your
program to kill, rather than the one of the program he wanted to
kill) should be treated as an exception.
My statement is provocative. But it was meant to be provocative
in a positive sense: to provoke you to define exactly what you
meant by error in your statement. Because I'm quite sure you
don't really expect a kill -9 to your program to be converted
into an exception, even if it is the result of user error.
And surely you won't dispute that there are different types
of errors If all of these are to be called "errors", they we
definitely have a case where one size does NOT fit all.
All caps? Really?
As you know, exceptions are not "one size." Exceptions fit
into hierarchies, with different types of exceptions
representing different kinds of errors. Something that could,
in principle, have been detected at compile time, should be
represented by a std::logic_error. Something that goes wrong
at runtime should be reported by a std::runtime_error, and so
on.
But they're still really one size---it's always the same
mechanism that comes into play.
They're not "really" one size.
They don't really have a "size" that can be measured:-).
They're "one size" in the sense that they all cause the same
mechanism to come into play, and require the same syntax to
catch. And have the same results if one doesn't catch them.
Generally, it's best to avoid it---in some ways, exceptions
are no more than a glorified goto.
C++ exceptions are not like goto.
The do introduce additional paths of control flow. Which makes
reasoning about the correctness of the code more difficult. If
the error is such that you're going to abandon a whole block of
functionality anyway, it may not matter---who cares if the
result is correct if you're not going to use it. And if the
error is in constructing an object, having to deal with an
invalid object is likely to introduce even more additional paths
of control flow than the exception did. In a very real sense,
exceptions are evil. In some cases, they are less evil than the
alternatives, but that's certainly far from true everywhere.
They are not an immediate transfer of control. They are a
special-purpose return path that unwinds the stack in a
predictable, orderly manner. Furthermore, a given
throw-statement does not always transfer control to the same
catch-block; catch-blocks are not labels.
All of which are arguments *against* exceptions, not in favor of
them. It's a goto where you don't know where you're going, and
when you get there, you don't know where you've come from. A
total disaster when it comes to any reasoning which depends on
control flow.
If you're claiming that
libraries shouldn't throw exceptions, well, that ship has
sailed, and good riddance.
Really? The only exception I might get from any of the
libraries I use is std::bad_alloc, and in a lot of cases, I've
replaced the new_handler with one which aborts, so I don't have
to worry about that one either.
(I know, the standard basically says that unless otherwise
documented, any function in the standard library can throw
anything the implementation wants. In practice, of course,
quality of implementation issues ensure that you won't get
unexpected exceptions. Which you couldn't handle anyway,
because you don't know what they are.)
Note that the typical ostream usage is a case where you
*cannot* use exceptions. Because of internal buffering, the
error may not show up until close, and if another error
occurs, triggering an exception, close will be called from a
destructor, leading to termination.
I see this as a serious shortcoming of the
language.http://groups.google.com/group/comp.lang.c++.moderated/msg/b7=
eddc4f0d...
So propose something that would make it work, in a reasonable
way.
Did you follow the link? There's a snippet of code in the
middle that was a first-order suggestion for how to handle
simultaneous exceptions within a single thread.
I didn't look at it in detail, because I'm not the person who
would have to decide. If you wrote up a detailed proposal, the
committee would consider it. I've my doubts as to its
workability. And the problem isn't so much implementation, but
specification of what happens when you have several exceptions
propagating in parallel.
The reason it isn't supported is because no one really knows
how to handle it (for several reasons). To be quite frank,
it doesn't really bother me---destructors and constructors,
in C++, have a very definite role: once you enter the
destructor, the object ceases to exist. Anything which
requires error handling should not be part of a destructor.
By that logic, ~fstream shouldn't call close.
And maybe result in an assertion failure if the file isn't
closed before the destructor is called. It's a compromise (and
I've seriously asked myself if the assertion failure isn't a
better solution): the close in ~fstream is a "backup" solution.
In correct code, at least in ofstream, it shouldn't be used
except when unwinding the stack as a result of an
exception---when you've encountered another error serious enough
to imply that the file you're writing won't be usable anyway.
My usual idiom (wrapped in an OutputFile class
which derives from ofstream)
std::ofstream is really not meant to be derived from. Is
this, at least, private inheritance?
Are you kidding?
No, are you?
std::ofstream is part of a hierarchy, which is definitely
designed with inheritance in mind. In the end, they all derive
from std::basic_ios.
Are you aware that ofstream hasn't got any virtual member
functions, including the destructor?
std::basic_ios has a virtual destructor. Thus, every class
which derives from it has a virtual destructor.
It's obviously not a metaprogramming support class like
binary_function, either. The intended use for ostreams is
that you derive from streambuf, not from the ostreams
themselves.
One doesn't preclude the other. Almost every time I've derived
from streambuf, I've also derived from istream or ostream (or
both), in the same way ifstream derives from istream and
ofstream derives from ostream.
The type is an std::ofstream, in all shape,
form and fashion. With just an additional feature.
If somebody tries to deletes your type through a
std::ofstream*, they'll get undefined behavior. You've just
lucked out of type-slicing, since ofstream isn't copyable. At
the very least, you could make the inheritance private, and
add using-declarations for the relevant members of ofstream.
Actually, what I'm really interested in is the members of
ofstream's base, ostream. But I'm also interested in the
non-member operator <<. (Also, my class wasn't really designed
to be allocated dynamically---it's a classical RAII, which
counts on the implicit destruction when the object goes out of
scope. It can be allocated dynamically, of course, but there's
no real point in using it in such cases.)
Note that while saying that ofstream is not meant to be derived
from is simply wrong, I am sensitive to arguments saying that it
wasn't designed for the extentions I've provided. And I'll
admit that it is a compromize. I'm used to wrapping ostream's
in a lot of contexts, and I definitely considered that
possibility. In the end, however, it seem to impose too much
extra code in the client, for purely theoretical
considerations.
is to have a commit function which does the close. If this
fails, or if the destructor is called before commit, the
class deletes the file it was writing, to prevent users from
accidentally using the incomplete file.
How does the class delete the file without closing the stream?
Well, I don't set up the streams to throw, so there's no
problem. It just ignores any error. Which is reasonable,
because the file concerned with the error will be deleted
anyway.
OK, I see what you mean, but not how exceptions have anything
to do with it. You're saying that close failed, so you delete
the ofstream; what I was saying is that ~ofstream will call
close again, but you've already stated that after the first
error, the subsequent operations are no-ops. This should
prevent any further error, regardless of whether we're using
exceptions.
No. Basically, the class contains a bool, isCommitted,
initialized to false. The function commit() closes the file,
and if there is no error, sets isCommitted to true. In the
destructor, if isCommitted is false, I call remove on the file.
The destructor also calls close on the ofstream as well, before
this, and without checking the error status of close (because if
the file wasn't already closed, we're going to delete it
anyway). (Or if it doesn't call close now, it will---to date,
I've only used the class under Unix, where remove() on an open
file works, so I may have forgotten the manual close before
remove()).
Anytime a stream is in failed state (failbit or badbit set),
all operations on it (except things like clear, of course)
are guaranteed to be no-ops.
That certainly suggests that the intent was to support your
favored use model of checking once, at the end, rather than
after each operation. I had not previously heard of that.
Do you really check the status after each output?
I don't have to, because I use exceptions.
That's actually a reasonable possibility for output streams; an
output error is usually pretty bad. On the other hand, another
error which results in a throw may cause the stream to be
destructed, calling close, and bang.
What "bang?"
The result of a second exception being raised. (You're right,
it's not automatic. Most of the time, the close will probably
succeed, and everything will work fine. Except, of course, when
you do the critical demo in front of your most important
client.)
For whatever reasons (and history obviously plays a role),
streams aren't really designed with exceptions in mind. I'd
avoid them with streams.
So you've made clear. Nevertheless, streams have explicit
support for exceptions, and I have found it beneficial.
The support was added as an afterthought. I'll admit that I've
never used it, and I'm very suspicious of it. A function that
might report its errors with an exception, or might report them
using other means, is worse than one which always reports them
with an exception. I'd be very sceptical, for example, of
passing a stream with exceptions activated to a third party
library---theoretically, the possibility exists, so the authors
of the library should have taken it into account, but
practically...
[...]
And for input, it's probably not appropriate.
Well, that's characteristically vague and unjustified.
OK, let's be clearer. There are three possible "error" bits in
ios_base, eofbit, failbit and badbit. You can activate an
exception for each of them. For eofbit, of course, there's no
possible correct use for doing so (and the fact that you can is
indicative that the possibility for exceptions was just added
on, without thought). For badbit, except for the problems with
close in the destructor, I suspect that if the streams had been
initially designed to use exceptions here, it would have been
more appropriate---I can't really imagine any case where you'd
be able to handle the error in the calling function. For
failbit, on the other hand, you almost always have to process
the error in the immediate calling function, so exceptions are
not really appropriate.
You've confused "refusing to consider" with "having
considered and rejected, in favor of a superior tool."
No. You've considered once; maybe exceptions were the
appropriate tool for that case, but that doesn't mean that
they're appropriate for everything. Each case is different, and
you have to consider each case on its own merits.
That's an unfounded accusation, and a personal insult.
You're being over sensitive. You've been arguing that every
error should be handled by an exception. That's definitely a
categorical statement.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34