[Clam-devel] re: refactoring backends (2)

[dirk.griffioen]

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, 
it could
- set it's own AssertFailedHandlerType
- call ExecuteAssertFailedHandler

A backtrace might be usefull, but then I need to make the DumpBacktrace 
public.

D




> 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...
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20090609/e480e4db/attachment-0004.htm>