Catch (...) hinders debugging

General JUCE discussion
1

ThreadPool::runNextJob contains

try
{
    result = job->runJob();
}
catch (...)
{
    jassertfalse; // Your runJob() method mustn't throw any exceptions!
}

I have a scenario where a dependency I’m using did throw an exception, but the experience of finding out what it was required first removing two catch-alls in JUCE first.

Without the catch-alls, Xcode brings me straight to the exception with the helpful error message explaining how I mis-used the API.

Wouldn’t it be better if these catch-alls existed only in release builds?

Cheers, Yair

4 Likes
2

It would be safer to remove the whole catch block. Or setting the result to a new error state in the catch.
I don’t like code that runs in debug mode and crashes in release build.

3

Both the current state and my suggested state are when code crashes in debug mode.

4

I’m forever having to go and comment out those to find out where I’m throwing an exception that I didn’t intend to. I don’t want to throw an exception in release either, so perhaps it would be better if they didn’t exist at all. Maybe someone from JUCE team can weigh in on the rationale behind these catch-alls, because one assumes they exist for a reason.

1 Like
5

Most IDEs let you set ‘exception breakpoints’ which pause execution when an exception is thrown rather than when it is caught. Using exception breakpoints sounds safer than intentionally allowing unhandled exceptions to escape.

3 Likes
6

That’s good to know and I might try it next time, but:

  • Setting an exception breakpoint is an additional step, better not to need it
  • You may use a dependency which uses and catches exceptions internally without you needing to know about it, and you wouldn’t want to break on these