Re: Descriptive exceptions
Alf P. Steinbach wrote:
* Eugene Gershnik:
On Feb 20, 6:58 pm, "Alf P. Steinbach" <a...@start.no> wrote:
* Eugene Gershnik:
[snippety-snip]
Who of course must speak English...
English is the lingua franca of software engineering.
English is also the lingua franca of commerce, but I don't use
it with the baker from whom I buy bread. For international
projects, everything must be in English. For in house projects,
if the company isn't multinational, there's no strong reason to
have this rule, and most of the projects I've worked on over the
last ten or fifteen years have used French or German for
logging, or messages in exceptions. (Where I currently work,
the user interface is in English, because English is the lingua
franca of banking, and we have users in most major markets. The
logs are in French, because the development group is based in
Paris, and uses normally uses French in internal discussions.)
It's no fun to
work on source code and documentation partially in Norwegian, Swedish
(possible to understand for us Norwegians, but), Finnish (not possible,
unless you know Finnish), English and Icelandic. Which I've done.
By standardizing on English such problems are mostly avoided.
I don't know. At least if it is in Finnish, you know you don't
understand it. Whereas sometimes, with English that was written
by a non-native speaker...
[...]
Now for the "as much internal information as you can" in the exception
itself. No, that isn't a good idea, and that's because of the reasons
snipped above: all that information is in most cases baggage of very
negative worth. It not only slows things down to collect it and copy
it, but collecting it and copying it can introduce additional failure
points and failure modes (as I illustrated with a concrete example),
which then invoke the exception-within-exception troll, and it
complicates the system, which has the same effect plus some.
But you propose logging the info at the throw point which would
require collecting the same info thus slowing things down and invoking
the problem-within-problem troll ;-)
To clarify:
Q. Are absolute rules good?
A. No, never!
I don't propose always logging exceptions at the throw point, only, as I
wrote, if you can, and that was in the context of exceptions being
logged anyway. If you're going to log all exceptions anyway, making an
initial log entry at the throw point guarantees that that exception will
be logged. Such a guarantee helps you guard against (1) client code
that doesn't log as it should, (2) crashes, with no (useful) log entry,
and in addition it (3) centralizes things, which is generally good.
All of which are very pertinent arguments. Qualified, as you
did, by "if you can". Nobody expects the impossible, but when
an error is discovered, the earlier it is logged, the better.
Supposing you are in a context where logging makes
sense---there's no point in logging, for example, if you are
writing shrink wrapped software, and will never get to see the
log.
There is no difference between logging at the throw point and at the
catch point from this perspective.
KISS - Keep It Simple, Stupid.
How did this pass moderation?
{ Presumably because the poster referred to a well-known software
engineering principle. Alas, the moderators cannot suppress references
to such principles even when the principle's name might be interpreted
as insulting (earlier mentions of the KISS principle don't seem to have
drawn comments in this group or in comp.std.c++, but there is the
possibility that such comments have been made in rejected articles). See
<url: http://en.wikipedia.org/wiki/Kiss_principle>. -mod/aps }
I can only confirm and if possible amplify what Alf-with-mod-hat-on
writes above (of course, only regarding my own intention, not what the
accepting moderator was thinking), that the statement was a direct
reference to the well-known software engineering principle, and I
apologize for not providing the clarifying link & perhaps a smiley then
;-). That said, I'm not an adherent to the political correctness school
of thinking. The Wikipedia article starts out by using a politically
correct new-speak expansion of the acronym, one I've never heard used,
which I think is wrong for an encyclopedia, but refers in turn to
sources that only use the well-known & meaningful expansion I provided.
Well, the Wikipedia isn't reknown for its accuracy, so giving an
unknown expansion isn't perhaps so surprising. The only
expansion of the acronym I've heard is the one you give; as you
say, it's a standard acronym, which despite its literal meaning,
isn't normally interpreted to be a personal insult. The other
name for it is Occam's razor, but Occam didn't formulate it in
quite those words---I think what he actually wrote was
"Pluralitas non est ponenda sine neccesitate"---Latin was the
lingua franca of philosophers back in the early fourteenth
century, when he was writing. Which makes me thing: maybe we
should write all our logs in Latin. That way, no one national
language is favorized. And there's certainly a precedant for
using it as the international lingua franca. (It also has the
advantage of not requiring any accented characters.)
mostly, except for logging at the point of throw,
Logging at the point of throw needlessly spends CPU/IO and
adds noise to logs even when exception is benign and
handled graciously. More importantly it requires each and
every component in your system to be aware of whatever
logging facilities you use. Which doesn't work well with
3rd party libraries or multi-component projects in
general.
Sorry, to me that's not a meaningful statement (no meaning extracted).
Let's try again. How are you going to log? What log facility are you
going to use if you write a library for an unknown client? Do you
intend to require a logging callback? Or write to your own
mylibrary.log file and ruin my nice logging scheme?
Additionally why would you force your logging (necessarily
synchronized and necessarily slow) on my thread running your code
*even if I don't want you to*?
Those are engineering decisions. Obviously the Windows API, say, cannot
be forced to log on your behalf (well, unless you're using a part of the
API that can be configured that way: one should never say never). So
mostly the answer is, "it depends": there's no silver bullet, but hard
trade-off decisions to make.
I wonder if the real disagreement isn't more concerned with what
exceptions should be used for, and the role of logging. If I
don't expect the application to catch the exception, and somehow
recover, I'll call abort(), and not throw an exception. I'll
log at the point of throw because that's where I have the data,
and can provide the most detailed information; there's no point
in propagating the information up to code which isn't interested
in it. I want the low level information in the log; what I
propagate will typically be something much higher level.
In the end: exceptions are for communicating to other parts of
the program; the log is for communicating to the developers.
The needs of the two are different, which means formulating two
different messsages when the problem is encountered. I normally
only use exceptions for very critical errors, and so want them
logged, but there are exceptions.
(And of course, you're point about something going wrong higher
up is also valid. Error recovery procedures are often the least
tested parts of the code---some errors simply cannot be
simulated. And if you crash, you certainly want to know what
happened just before, in order to maybe be able to reproduce the
problem, or at least know that you can't.)
[snip]
At the point of throw it's not known what may happen later.
Hence at that point, the code must act as if anything can happen.
Precisely ;-) Which to me means not do anything other than throw.
What do you trust more to not screw up: arbitrary client code above that
has demonstrably violated your preconditions or resource requirements,
or a true and tested logging facility?
If the arbitrary client code has demonstrably violated
preconditions, I want to abort (after logging), not throw an
exception. On the other hand, it's a pretty rare application
where the logging facility hasn't been tested considerably more
than the error recovery procedures.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]