Hacker News Reader

Comment by CyberRabbi | Hacker News Reader

> Surely you agree that it's better to have this throw an exception, and a big try.. catch around your audio callback so that just this tick

Yes I do agree but my point is that if any exception is being thrown for the sake of being handled then your Audio code is bad.

Generally your Audio loop should encounter no errors at all (it should be a pure process) so what the OP is saying is that excepting/aborting is fine in that case because it would truly be exceptional. I can’t imagine what the exceptional situation would be but to the extent one exists, I agree with that. My only point is that throwing an exception when there is no handler is no better than calling abort(), obviating the need for enabling exceptions.

View on HN

> Yes I do agree but my point is that if any exception is being thrown for the sake of being handled then your Audio code is bad.

thank god ! then we both agree.

> Generally your Audio loop should encounter no errors at all (it should be a pure process)

and audio handlers should never lock mutexes yet I have seen my fair share of them in the wild.

> My only point is that throwing an exception when there is no handler is no better than calling abort()

every thread or event loop should always have a catch-all handler at top level.

> and audio handlers should never lock mutexes yet I have seen my fair share of them in the wild.

They are incorrect. Only bounded-time synchronization primitives can be used. E.g. lock-free queues.

> every thread or event loop should always have a catch-all handler at top level.

Two things. 1) There should be no reason for a properly coded real time audio loop to have a top level handler because exceptions should not be thrown because they cannot be guaranteed to be handled within the necessary time constraints.

2) top level exception handlers divorced from context cannot be handled, only ignored. Ignoring exceptions is very dangerous because there is generally no way for the top level handler to be sure that the rest of the program is in a correct state (unless it knows all code is exception-safe, which is rare). Continuing to run can result in data corruption. Exceptions leaving the context that has the information to handle them is a programming error, just like a failed assertion.

> They are incorrect. Only bounded-time synchronization primitives can be used. E.g. lock-free queues.

yes, my point is that incorrect code exists in the wild, that's the world we have to live in.

> properly coded real time audio loop

most things aren't properly coded, and yet still useful

I see a difference between bugs and design flaws.

Reply on news.ycombinator.com