[Clam-devel] refactoring backends (2)

[David García Garzón]

Another thing to note in the example code you sent. Those exits should be 
replaced by something else, being exceptions, assert or whatever. The problem 
is that some low level code like this is cut and pasted from some library 
example which didn't care about the application exiting. 

Exit on error is not an option in CLAM. We want to respond to those errors. In 
CLAM style this is:
- An typed exception if the calling function should handle it (runtime 
conditions, user errors...)
- An assertion if it is a programmer error (unmet/unchecked/unassured 
preconditions).

Some rogue sources that still use exit on error conditions:

CLAM/src/Flow/Networks/BackEnds/JACKNetworkPlayer.cxx
CLAM/src/Flow/Networks/BackEnds/OfflineNetworkPlayer.cxx
CLAM/src/Tools/AudioIO/RtAudio/RtAAudioDevice.cxx (deprecated)
CLAM/src/System/Threads/Watchdog.cxx (just used in Rappid oldapp)

David.


On Monday 08 June 2009 15:08:42 dirk.griffioen wrote:
> Hi,
>
> Would clam be interested in the ENFORCE idiom? Basically these are
> asserts, but they are kept in release mode and throw(). The rationale
> you can find here: http://www.ddj.com/cpp/184403864
>
> I have found they lead to much smaller and safer code as for instance
> preconditions/invariants are 'enforced'.
>
> For example, before:
>
>
> and after (please note the example is not too good: destuctors should
> not throw ...)
>
>
>
> It generates errors like this:
>
>
>
> But this might be too much what CLAM_ASSERT already does ...
>
> Dirk
>
> PS - attached the header