The jassertfalse macro is defined as:
#define jassertfalse { juce_LogCurrentAssertion; if (JUCE_NAMESPACE::juce_isRunningUnderDebugger()) juce_breakDebugger; }
which is not the behavior I’d expect, rather I’d expect it to break even if I’m not under a debugger (to have the option to break into the debugger). This is a bit nasty as an assertion that should notify me of an error won’t be discovered unless running in the debugger.
Well that’s only possible on windows - on linux/mac if it asserts, the program just exits, which isn’t very helpful.
Good point though - maybe I should move the debugger test to not happen under windows.
But if you do that, anyone not having Visual Studio installed will see a wonderful “This program has done an unexpected operation” dialog.
Remember, it’s only when Visual Studio is installed that it installs itself as JIT debugger.
Regular users default to Dr. Watson, which only show a “crash” dialog.
Surely, if you want to debug your software, run in under a debugger.
If not, then don’t block every user expecting them to have something configured like your dev computer.
Yes, I know about the release build, and so on… But when you’re in a dev phase, sending daily updated version to your beta tester, you don’t “release” them, but you except them to run your software by logging assertions, not stopping it.
Yeah, I do agree with that. In non-debug code, it’ll log the assertion and carry on, which I think is what you’d want to happen. And if you want to debug it, run it in the debugger. (I don’t think I ever run my debug builds outside the debugger)
