Juce deserves a break


#1

I’m trying to use juce_breakDebugger but it is only defined if JUCE_DEBUG is defined. And of course, I’m building the Release version of my app.

I would like to be able to call juce_breakDebugger no matter what the build target, could we break this out into its own different function or macro independent of the setting of JUCE_DEBUG or JUCE_FORCE_DEBUG ?

Or, if I am hopelessly confused about the way this macro works please enlighten me.


#2

Yes, that’s a pretty reasonable request… I guess it always be defined in case you want to use it - I’ll have a look and do a bit of tidying up. Cheers!


#3

Awesome! Cross platform break-to-debugger!

I don’t use exceptions to handle errors because they are yucky. However, I do use them to indicate logic errors (like array index out of bounds, or invalid iterators) and when they get thrown I want my app to terminate, even in release builds so that my users can reproduce it and then I can track it down. I also build symbols into my Release executable so my programmer friends can give me a stack while they test.

But the problem with Visual Studio 2008 is that it seems impossible to get a breakpoint at the throw line. It always breaks after the throw and I can’t see where the exception came from. Using this simple function solved the problem:

template <class Exception>
inline void Throw (const Exception& e)
{
  juce_breakDebugger; // lets you get a breakpoint at the throw line
  throw e;
}

So that’s why I want juce_breakDebugger (or some other name) available no matter what, on all platforms. It is quite handy.


#4

If it’s your own exception class, you could always just put the break inside the exception’s constructor?


#5

I thought of that but actually…some of my exceptions are okay (i.e. don’t terminate) and happen regularly but also I throw standard exceptions in some library-style code.

What I REALLY need is a way to get a breakpoint at the throw line, because I don’t have a good way to catch standard library exceptions or exceptions thrown from third party libraries…the stack is always screwed up and the program counter is not at the place where I would like it to be (i.e. the throw line).


#6

Oh yeah and its also nice to be able to skip the throw in the debugger, return to the caller and then poke around by setting the next statement and inspecting things.