Re: Why do some code bases don't use exceptions?
On Nov 25, 10:46 am, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
On Nov 22, 6:25 am, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
On Nov 21, 2:57 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
James Kanze <james.ka...@gmail.com> wrote in
news:f37f1e13-cdcc-4144-
b526-364f2bcf6...@s31g2000yqs.googlegroups.com:
On Nov 17, 8:43 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
krel <k...@example.invalid> wrote
innews:hduq8e$4f9$1@news.eternal-september.org:
and badly designed feature".
In C++, there are surprisingly few "broken and badly
designed features".
That's very arguable. The question isn't so much whether
C++ does it right; it's usually a question of other
languages not supporting it at all.
Non-empty exception specifications are one example,
Broken and badly designed, or simply a more or less good
solution without a problem?
I would say broken and badly designed as they solve even the
perceived problem inadequately (app termination is not an
adequate solution imo, and catch(...) is better than using a
global unexpected handler).
What is the perceived problem? And why is aborting (as a
default behavior) a bad solution?
I've watched these threads before and found that they go
around and around. The reason is because you all are jumping
the gun seeking the "one and only" thing instead of being
patient and doing some research. Error handling is
application-specific.
Even within a single application, different types of errors will
require different types of handling.
But that was my point: "one and only" mechanism is the
"looking for the silver bullet" approach.
So we agree. (On that, at least.)
For that matter, the same type of error may require
different handling in different contexts: a write error in a
log file should probably be ignored; a write error in the
program output (e.g. when writing the object file in a
compiler) should probably result in the program terminating
with an error status (after clean-up---I can't think of any
case where a write error should result in an abort).
Without a well-defined problem, discussions get no where
toward solution and no one learns anything. James, you
said, "aborting is not necessarily bad". Well, of course
not. It depends on the application.
Which is what I said. Most of the time, aborting is the
appropriate reaction,
Reaction to what is the question. You must have something(s)
specific in mind.
When you detect a coding error (a violation of a precondition,
for example), aborting is *usually* the most appropriate
reaction. Not aborting should only be done in explicit cases,
where you understand the issues and are prepared to cope with
them.
and it is the obvious choice for a default action,
Along with logging, backtracing, notification, perhaps
restarting from checkpoint, maybe rollback, maybe switching to
redundant system 3... Application-specific. Perhaps the only
place abort is appropriate is in language newsgroups! ;)
Abort is generally the most effective means fo switching to the
backup system. It's the generally accepted means of reacting to
software errors. More generally, if a program is doing the
wrong thing, it generally should be stopped as quickly as
possible, so that it doesn't do more of the wrong thing.
but I'm well aware that there are exceptions: game programs,
for example, and possibly light weight GUI client code.
It is but one of many avenues to take upon detecting
(detection is a key concept) that a potentially
"disastrous" thing will occur unless processing doesn't
take a side road immediately. If you believe what I just
said, and I believe you do, then you see why I question
those who consider C++ exceptions as an error management
strategy. C++ exceptions are JUST a mechanism. NOT a
solution to the error management problem.
I don't think anyone has reasonably argued that exceptions
are an "error managment strategy". First, as you say, they
are a just a mechanism---a tool to implement a strategy, and
not a strategy. And second, they only address one aspect of
error management: reporting.
They don't do that at all. Exceptions are an error propogation
mechanism in C++,
Error propagation, error reporting: same thing, really.
Propagation is probably the better word, though; it just slipped
my mind.
an probably best to use sparingly for places where local
"handling" is not possible (constructors, for one) or not
appropriate (independently developed libraries).
Exactly.
Reporting comes after exceptions have done their part.
I think we're talking about different things. I was talking
about "reporting" the error to the location in the code where it
would be handled.
Error management involves three aspects:
detection, reporting and handling.
There is also: error definition & categorization and propogation.
Propagation is reporting, at least in the sense I was using the
word. Categorization is probably part of detection.
So I see at least 5 things. If I ponder a bit more here, I may
come up with a few more things.
You can certainly define it a lot finer, and there's often a lot
in each of those words. My basic idea was that you have to
think of errors in three contexts: where you're going to detect
the error (e.g. how, what type of error, etc.), where you're
going to treat it (log it, retry, etc.), and in between, where
you have to propagate it from where it was detected to where it
is to be handled.
I do know that I wouldn't call simply
detection/handling/reporting "error management" though, and
that's not what I meant when I used the terms. Documentation,
communication and enforcement of the prescribed or chosen
strategies and patterns are a few more (see, I came up with a
few more in 1 minute). "Error management" as simply
detection/handling/reporting? Nah. No way.
At the coding level:-). I totally agree, my categorization
doesn't cover things like documentation and communication (to
other programmers), and they are very important.
Exceptions don't help in detection, nor in handling. They
just simplify reporting when the error must be handled far
up the call stack.
That's propogation, not reporting.
Two words, same thing.
(Which means that they are of no use when the error must be
handled immediately.)
Catch = handle error
Yes, but having to write a try block, then a catch statement, is
more complicated than an if, if you want to process the error
immediately. You can use an exception, but it's about like
pealing a grape with a butcher's cleaver.
--
James Kanze