Re: A matter of exception reporting style
On Aug 12, 5:46 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* mzdude:
On Aug 12, 9:23 am, "Alf P. Steinbach" <al...@start.no> wrote:
Should derive from std::runtime_error.
[...]
We don't use narrow char unless forced to for historical
interface reasons.
For exceptions you should.
There is AFAIK no reason to support wide characters in
exceptions.
It depends...
The same internal failure can cause different user level
failures; different internal failures can cause the same user
level failure; and the requirements on information conveyed,
internationalization etc. are vastly different.
So user interface messages should ideally not be carried by
exceptions.
Totally agreed, but the exception must carry all necessary
information, which might include things like the user name, a
filename, the actual data base request which failed, why the
request failed, etc. And some of these might only be available
as wide character strings. (I've not encountered the problem
myself, since I tend to use UTF-8 for all of my text. But it's
certainly a potential problem, especially under Windows, where
filenames, etc. may be wchar_t strings.)
That way exceptions can more easily be propagated across C
code, e.g. from callbacks.
Not sure what you mean by this.
It means that before returning to C code that was called by
your code, you can dynamically copy the exception somewhere
(for complete generality it helps if it supports cloning), and
on return from C code you can rethrow the exception with
original type.
Just a reminder as well---threading almost always involves C
interfaces at the lowest levels; you'll need to clone and
rethrow the exception if you want to propagate it over a join,
for example.
For the C code in between may not support exception
propagation.
In the case of join, it almost certainly doesn't, since
exception propagation involves stack unwinding, and you're
moving from one stack to another.
Take care not to make that error code/string the primary
message (as it seems to be above), but just a convenience
add-on.
That is the case. The error code is the important. The
message is for the human (maybe).
If you make the error code the important, then you're most
probably heading for the nightmare I mentioned.
At the worst you'll end up with a repository/database of error
codes and strings, a set of small utilities for handling that,
a person in charge of that, and umpteen man-months wasted
searching for proper error codes or creating them.
Yep. That's life. It is, regretfully, something you can't
really avoid. (But correctly managed, it's not very expensive.)
Generally all that matters for code that handles an exception
is that there was an exception,
Generally isn't always. If a transaction fails because of some
erroneous information the user entered, it's very useful to be
able to point out to him what that information was. When a
server returns an error, it should return a maximum of
information, so that when the GUI client receives the error, it
can e.g. highlight the erroneous fields in the input form,
perhaps even indicating precisely what was wrong with them.
--
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