Hi, Without being directly a Muse developer, maybe a few comments:
> On 2017-05-13 08:40 AM, Robert Jonsson wrote: >> Hi guys, >> >> I've been experimenting with adding RtAudio support to get additional >> audio backends, sadly RtAudio works really badly unless you can have >> exceptions (not a good design of that part of the library IMO, but >> still). >> Thought I would just ask, as we define no-exceptions, is there a known >> reason for this or is it just out of old habit? >> Probably the binary is a little bit smaller with no-exceptions but >> otherwise I'm uncertain it makes any real difference. Exceptions bring a few headaches with them, so probably it was a good decision. At work I am developing on a mission control system and have been bitten by exceptions quite some time, as it is quite hard to get exception safe code. Still, I have not really a deep knowledge of the Muse Code Base, therefore of course, the decision should be up to you. So please, see this just as some comments and random thoughts :) Just some points: - Exceptions need everything to be safe, which often means heavy usage of RAII for resource management, especially of Mutexes and memory (i.e. means the use of Smart Pointers). Sometimes this needs serious refactoring to get there. - There are different exception guarantees, that should be met e.g. from Stroustrup himself: http://www.stroustrup.com/except.pdf or here from the boost folks: http://www.boost.org/community/exception_safety.html - be careful with exceptions and multi-threading. While there are no asynchronous exceptions in C++ (which provide another can of worms, that's why Java dropped them again), the pthread library, which on Linux is the native threading library uses the C++ exception mechanism under the hood to cancel threads. If you call pthread_cancel (or a threading library does that under the hood e.g. boost::threads) in reality it raises a C++ exception that MUST NOT be caught. We had this two times in the mission control system, where we added a catch(...) clause and the process aborted with FATAL: exception not rethrown because someone used a pthread_cancel. Most people are not aware of this. - the only real guarantee you have from methods with nothrow, all other methods can in principle throw all kinds of exceptions, no matter what throw specifiers are there (e.g. std::bad_alloc in principle everywhere where operator new is used). Now working a lot in Haskell (which also has exceptions and also asynchronous exceptions) I came to really don't like them since especially because of Haskells lazy evaluation you often don't know when the exception can and will be triggered. So currently I avoid them as much as possible. Anyway, in case of RtAudio maybe it would be possible to provide a thin wrapper around it to catch them and convert them into error codes? Depends of course on code division, build system etc. > > Still curious, a few years ago I Googled exceptions + Linux. > Wow, some folks said exceptions are evil. Well, they have their uses, but the unexpected downfalls sometimes make them hard to justify :) I really had some unreproducable deadlocks because an exception terminated a block which was locked by a mutex without a ScopedLock or similar. Trying to debug stuff like that can drive you crazy... lg, Michael ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
