Re: Descriptive exceptions
* Eugene Gershnik:
On Feb 22, 1:29 am, "Alf P. Steinbach" <a...@start.no> wrote:
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.
Great we are almost there ;-) Now, how do you, as an author of at(),
know whether it is the normal case or client error?
at() is a function that you'd never want logging for. At least, I
wouldn't, normally, and when I would it's simple to wrap. But assume
that at is a function that can fail in a way that you'd want logged.
The problem is then to decide whether to log or not, which is simple.
Deciding whether the client code's in error is, on the other hand,
generally impossible for the called code -- with today's technology
only analysis by a human can do that determination.
The only way for you to know is to ask your caller.
Sorry, with a literal reading that's incorrect: you can't ask the caller
whether the caller's in error. You can ask the caller whether to log,
in principle. But in practice it's better to have that transparent to
the called code, or to just know.
Illustrating the last first, if foo() is a function corresponding to
some action for which failure should always be logged, then simply do
T& foo( std::size_t )
{
whatever1;
if( bad ) { throwWithLogging( "details" ); }
whatever2;
}
This is the basic case: it might be part of the same code (set of source
code files) that will eventually catch the exception, but there are
numerous catches and call paths down to foo, and foo itself here
constitutes a single point of initial and guaranteed logging.
If foo is, on the other hand, a function whose failure should in some
cases be logged, and in other cases not, depending on the call context,
you can do
T& fooA( std::size_t i, bool doLog = false ) ...
or
template< class Logger = NoLogging >
T& fooB( std::size_t i ) ...
or
T& fooC( std::size_t i )
{
if( i > n ) THROWX( "Argument 'i' too large" );
return something;
}
or something else.
For case C THROWX might access a per-object member or a module variable
or a global singleton, whatever, that determines whether logging is to
be done or not.
Client code for the dynamic (non-templated) foo might look like
void fooFighter()
{
Logging logging(); // Turns logging on in this scope.
whatever1;
foo();
bar();
whatever2;
}
void fooFriend()
{
Logging logging( false ); // Turns logging off in this scope.
whatever;
foo();
bar();
}
void fooAgnostic( bool doLog = true )
{
Logging logging( doLog );
...
}
And there might be levels of specificity, e.g. global logging state
overridden by local logging state, logging for specific types, etc.,
whatever the client code needs.
Which can be generalized by letting the client code control the
mechanism that in the end supplies 'true', yes do it, or 'false', no
don't, to the (attempted) log call in the called code.
Which you already do by throwing an
exception but you don't like relying on it so you (if I understand
correctly) propose to ask via some sort of callback (either run- or
compile-time).
I think I understand what you mean. Just for reference: the concept
that I think you're thinking of isn't a "callback". It is some kind of
communication of logging needs from client code to called code.
Note: the client code might be /any/ code.
Which to me precisely violates the much discussed KISS principle and
complicates your library. As a matter of fact very few libraries
follow this approach. I bet your standard library doesn't try to log
exceptions in at() or sets up logging callbacks ;-)
The standard library doesn't, because the standard library isn't
designed for logging. There's also much else that's bad about the
standard library (don't get me or someone else started on iostreams and
std::string and filenames and...). But, it isn't a perfect world, and
it's clearly much better with a standard library than without one.
Disclaimer: written late at night.
--
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! ]