Re: Necessity of multi-level error propogation
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:
James Kanze wrote:
Most compilers have options to exploit profiling data when
optimizing.
To the level of favoring a particular branch of an if/else
statement? Could you please provide some links? That
sounds useful, but I've never seen that kind of automated
feedback from the profiler to the compiler.
It should be documented in the compiler documentation. For
Sun CC, see the -xprofile option, for example, see the
section "Advanced compiler options: Profile feedback" in
http://developers.sun.com/solaris/articles/options.html, for
a quick survey. The linker for VC++ has a /PROFILE, although
I'm not very familiar with it.
Thanks, but none of that is remotely portable. Obviously,
it's not part of standard C++, or the de facto standard tool
chains.
By definition, nothing concerning optimization is "portable".
The standard says nothing about how you invoke the compiler, or
request specific options. As for the de facto standard tool
chain... I'd say that Sun CC was the de facto standard tool
chain under Solaris, and VC++ under Windows, so at least on
those platforms, it's part of the de facto standard tool chain.
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.
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. Generally, it's best to avoid
it---in some ways, exceptions are no more than a glorified goto.
But in particular cases, the alternatives have even worse
disadvantages, so they become the less evil.
In the terminology I use, many different things are
considered "errors". If my compiler core dumps, it's an
error, and if my C++ code which its compiling is missing a
semicolon, it's an error, but I certainly don't expect the
compiler to treat the two in the same fashion.
The use (or lack) of exceptions says nothing of how a program
will respond to an error. Exceptions are an internal
implementation detail.
They certainly affect the syntax of catching the error for
processing.
If a program receives bad input, and internally throws an
exception to signal this runtime error, it should still catch
the exception, and respond in whatever way it deems
appropriate.
If a program receives bad user input, using an exception is just
a way of making life more difficult for the client code.
Fallible and my preferred ostream use *are* distinct.
Fallible is designed to be checked immediately, and normally
is---it is for functions which return a value (but sometimes
can't). And you normally stop trying on the first error.
The ostream use (and IEEE floating point) is just to
continue on, as if nothing had happened, until the end, and
then check once and for all.
OK. I did not recognize that distinction, but it's clear now.
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/b7edd=
c4f0d...
So propose something that would make it work, in a reasonable
way. 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.
You have a decent point, but this is something that can be
worked around by making sure that the stream is owned at a
higher level of abstraction than the "working" code that might
throw exceptions. The higher level of abstraction can catch,
close, and rethrow. In general, the code that uses the stream
ought to accept a (semantic) reference to it, and should not
be the same code that owns the stream.
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? The type is an std::ofstream, in all shape,
form and fashion. With just an additional feature.
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.
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.
For whatever reasons (and history obviously plays a role),
streams aren't really designed with exceptions in mind. I'd
avoid them with streams.
E.i. you never do anything like:
std::cout << "label = " << someData << std::endl ;
without having activated exceptions for errors?
That's right. I may do it in a twenty-line toy program, but
certainly not in production code. I always activate
exceptions for errors, and would advocate that other
developers do the same.
It's dangerous, because it means that the destructor may throw.
And for input, it's probably not appropriate.
I think that there are a number of different solutions for
error reporting. I use at least four in my applications:
return codes, deferred checking (the iostream/IEEE floating
point model), exceptions, and assertion failures. For any
given error, which one is most appropriate is a judgement
call, and the fact that you choose a different one than I
would isn't necessarily wrong. Refusing to consider all of
the possibilities, and insisting that everything from
derferencing a null pointer to a trivial and recoverable
input error should be handled the same way, is. Refusing to
consider any one of the possibilities (e.g. exceptions,
which started this thread) is also wrong, although I can
easily imagine that there are certain applications where one
or more of the techniques never actually finds concrete use.
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.
Every time I start a new project, I don't have to do a special
study of whether Forth is the right language for the job. I
have a pretty good idea that it isn't, except under very
particular circumstances. Similarly, every time I consider
the best way to signal an error condition, I don't have to
make a "pros and cons" list of the various possible
mechanisms.
Interesting. Every time I start a new project, there is a
consideration of what language to do it in. Maybe not Forth,
because we don't happen to have it available, but the last two
green fields projects I implemented were in AWK, and not C++,
and most large projects use a mixture of languages, with some
parts in shell script, some in C++, some in Java, and some in
who knows what else. In one or two cases, I've even created a
domain specific language especially for the project.
--
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