Re: Descriptive exceptions
* Eugene Gershnik:
Alf P. Steinbach wrote:
Client code, on the other hand, is unreliable (it's in the nature of
libraries to be better tested and more reliable than their driver
code), especially in the context where the log is needed, where the
client code has failed. But perhaps best to repeat & rephrase. When
you have client code that has failed so that you need the log, what can
you say
about the reliability of the client code in that particular situation?
Why do you continue to assume that an exception is a result of any fault in
your client code?
No, I didn't continue to assume that, and I haven't assumed that (nor am
I continuing to beat my wife (well, if I had a wife: I wish! :-) )).
I was setting up a case, that's what e.g. "When" means.
You might argue that the case never happens in well-designed code, and I
might rebut that that's rather unrealistic, but the argument that I must
be thinking that this case is the only thing that ever happens is not
convincing to me.
Taken together with your statement about precondition
violations leading to exceptions I start to suspect that you use exceptions
as a replacement for assert() and crash.
No.
In reality exception is never an indication of client error even when you
use it to report "invalid argument". At the second you decide to throw when
the argument is "invalid" you in fact make it a perfectly valid ;-) For
example somebody might use vector::at() and rely on the excpetion to detect
when index is outside the bounds (sure he could have just checked size()
but
if index being out of bounds is extremely rare an unexpected condition then
it might make sense to simplify the code).
Yes, I've made that argument myself. It leads to multi-level contracts,
or "meta-contracts", much like real world contracts may have penalty
clauses about what happens on failure to deliver: its a second-level
contractual regime. The problem is that it's (AFAIK) not recognized in
the literature, so we have to make do with the simplistic black/white
picture of success sans exception, and failure with exception.
That should not overly constrain meaningful communication, however.
The main point in this regard is that when an exception is part of the
normal case, e.g. using at() as a checker function, logging is generally
neither required nor desired: the case I set up was therefore of a
different nature, namely, a situation where logging is desired.
--
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?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]