[Clam-devel] re: refactoring backends (2)
dirk.griffioen at barcelonamedia.org
Tue Jun 9 09:13:59 PDT 2009
Would this be okay?
CLAM_ENFORCE(infile->samplerate() == sampleRate) << "All the input
audio files have to have the same sample rate";
And remove the exit(1)'s from the code ...
I can add Assert.hxx to Enforce.hxx, so instead of doing it's own thing,
- set it's own AssertFailedHandlerType
- call ExecuteAssertFailedHandler
A backtrace might be usefull, but then I need to make the DumpBacktrace
> A Dimarts, 9 de juny de 2009 10:09:17, dirk.griffioen va escriure:
>>> But, of course, if this implies a change in the user code, in something
>>> that is as ubiquitous as CLAM_ASSERT, that's not a solution unless it
>>> pays the price.
>> What if I rename ENFORCE to CLAM_ASSERT_MSG?
>> You get lines like:
>> CLAM_ASSERT_MSG(jack_client_close(jackClient) == 0) ("JACK_ERROR: cannot
>> close client");
> It would be a nice addition. I would prefer the insertion operator than the
> call operator. This way we can easily turn regular traces into assertions.
>> Or should there be a tighter fit to the current CLAM_ASSERT?
> I guess that the behaviour regarding aborting, throwing, callbacks... should
> be the same of the CLAM_ASSERT just to keep consistency on the handling.
> Maybe that is not the behaviour you want for the network players. In those
> case we should create a diagnosis protocol for the backends: typed exceptions,
> diagnosis methods or return values, whatever it fits the better in the usage.
>> (For the record, I am not proposing to redo all, just start small by using
>> this where applicable).
> Perfect then.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the clam-devel