[Clam-devel] errorhandling
dirk.griffioen
dirk.griffioen at barcelonamedia.org
Wed Jun 10 07:13:52 PDT 2009
Hi,
David and me got into a discussion yesterday on howto deal with
errorconditions in CLAM with respect to reporting 'the right thing' to
the user. As David mentioned earlier, should we use errorcodes, typed
exceptions, diagnosis functions or ...
At the moment the codebase has different styles: (boolean) returns,
asserts (that may register their own handler), throw or even exit():
if ( jack_port_unregister ( _jackClient, it->jackPort) )
{
std::cerr << "JACK ERROR: unregistering port " <<
it->PortName() << std::endl;
exit(1);
}
if(infile->samplerate() != sampleRate)
{
std::cout << "All the input audio files have to have the
same sample rate" << std::endl;
exit(-1);
}
David made the difference between 'programmer exceptions' (violation of
invariants) which may throw (and possibly terminate) and 'user
exceptions' - things the user did wrong but should not terminate the
program; for instance, giving a wrong file may lead to the samplerate
exit as depicted above.
For 'programmer exceptions' I like the ENFORCE idiom over (clam)assert
or 'if condition throw error' - as it says what it does, without me
interpreting code; but opinions may vary here. Either way, 'programmer
exceptions' are, well, exceptional and should be caught by the main
catchhandler, logged and the program can terminate if it pleases so.
The big question now becomes, what to tell the user? The samplerate
message in the above example will not guide the user in choosing the
correct file.
But maybe if it were more like:
std::cout << "All the input audio files have to have the same
sample rate (did you open audiofiles?)" << std::endl;
this would give the user a hint ...
David suggested that lower level (user) exceptions should be handled by
the higher level, possibly translating them in something more
meaningfull (David, please correct me if I quote you wrong). The problem
I see with that is probably will get a large table of 'translations' and
what to think of the other causes samplerates do not match (corrupted
file, ...)
I would be all for a simple scheme: state your error and possibly hint
at a cause, throw and handle it as high as possible.
Secondly, I have a practical question: what kind of exception should I
throw? Do I need many types or could I do with 2, one for the progammer
kind and one for the user kind (please note, I am thinking aloud here).
class ClamUserException : Err {}
class JackException : ClamUserException {}
if(infile->samplerate() != sampleRate)
throw JackException("All the input audio files have to have
the same sample rate");
where the userexception may be shown to the user at some point ...
But I also understood this has been discussed out already - so I'd like
to know what the findings where in order to implement them to get rid of
these exit()'s ...
Best, Dirk
NB - how about
ENFORCE(infile->samplerate() == sampleRate) << JackException << "All the
input audio files have to have the same sample rate";
NB2 - An interesting read with nice references is
http://www.gamearchitect.net/Articles/ExceptionsAndErrorCodes.html
- especially the Guru of the Week reference is insightfull on
asserts/exceptions
http://www.ddj.com/showArticle.jhtml;jsessionid=30ZICNMFOENVCQSNDBOCKICCJUMEKJVN?articleID=184401979
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20090610/918b613f/attachment.html>
More information about the clam-devel
mailing list