[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-0003.htm>


More information about the clam-devel mailing list