Re: A matter of exception reporting style
On Aug 12, 5:11 pm, mzdude <jsa...@cox.net> wrote:
On Aug 12, 10:01 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
ISTM that the problem is not the slight discrepancy in the
strings, but their close ressemblance, assuming the two
conditions that raised the error ErrCode1 are different!
No actually the conditions are identical.
Actually, one problem is in the use of enums.
I don't see it that way.
I understand that for external references it might be useful
to have error codes, and that small integers might be
practical for such error codes. But internally, you
shouldn't have to deal with them.
This particular mechanism is for a progromatic interface.
Through a published API a calling program has violated the
contract. We are returning the results. In this case the
results will be formulated into XML (not that it's terribly
relevant).
<Result Status="Fail" ErrId="100">Reason for failure goes here</
Result>
The calling program can take corrective measures based on the
error code more easily than it can for text.
If the calling code is likely to want to distinguish between
types of errors, you probably need to make different types of
errors different derived types, so the distinction can be made
directly in the catch.
If the error is going to be propagated, and handled by a program
at the other end, then providing it with a numeric code is a
definite advantage. It still might need additional information,
however, and you should consider some means of providing this as
well. Transmission should generally be as text however, but in
such cases, I'd limit the text to a highly restricted set of
characters, unless the additional information required more.
For logging, it depends on the context. I don't think there are
any absolute rules. But on the server side, I'd recommend
logging before the exception is thrown (perhaps in the
constructor of the exception, but more likely by means of using
a macro to throw the exception---this is also a case where
you'll want Alf's possibility of throwing the exception from
within the exception).
For interactive users, the message should be formatted in the
user interface, using the information in the exception---the
exception itself should not be concerned with what the user
should see, or how the error will be presented to the user (but
it must carry all of the information that might be needed).
--
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