Use NSUserDefaults to set the value of “NSApplicationCrashOnExceptions” to true and your application will crash like it used to. Thus generating a crash report, showing you what went wrong and where. Opposed to silent failures, which are hard to find in console.
Given that I have an MBS license, I put the following into the Open event of my app:
#If TargetMacOS
Var u As NSUserDefaultsMBS = NSUserDefaultsMBS.standardUserDefaults
u.setBoolValue("NSApplicationCrashOnExceptions", True)
#EndIf
This seemed to update the auto-created file located at /Users/scott/Library/Preferences/com.mycompany.myapp.plist which now looks like the following:
I guess as long as that entry is in the plist file, the OS takes care of the rest?
You always have the greatest pointers Sam, thanks again!
If you’re on twitter; make sure you hit up @steipete and let him know it helped. I wouldn’t have found this tip without him. I’d started trying to get into the depths of handling NSExceptions myself, simply so that I was aware when, where and what was happening.
FYI - Scott
You can just add to the apps plist at build time by creating a text file named info.plist and then dragging it into the project
It lets you add key / value pairs to your build apps default plist
[quote=475025:@Norman Palardy]You can just add to the apps plist at build time by creating a text file named info.plist and then dragging it into the project
It lets you add key / value pairs to your build apps default plist[/quote]
Thank you Norman for the link, I knew there was a mechanism for including a plist in a project, but hadn’t had a chance to explore it much yet.
With some of the things I’d like to do, I know I’ll have to dig into this further eventually.
[quote=475025:@Norman Palardy]You can just add to the apps plist at build time by creating a text file named info.plist and then dragging it into the project
It lets you add key / value pairs to your build apps default plist[/quote]
Does it work if added to the application plist?
The usage described by @steipete is to set it to the defaults. Sadly it’s undocumented, so there’s no official word from Apple on this.
I don’t know; lemme check the documentation… Oh that’s right, it’s not documented.
I can’t tell you how happy I was when I read this tip. I had gotten to a point where I started to accept that 10.14 was just a fundamentally broken OS. I’d take me days to track down which API was breaking functionality, nothing was written to the log, so I just assumed that it’s broken.
Once I saw this tip and now use it all my apps, I started to test things that I thought were broken. Sure they’d changed in behavior, but with this, they’d crash. The crash log would then display the API that was causing the exception, and most importantly WHY!
I’ve pretty much been able to get everything working again.
This has to be one of the most ridiculous changes made to the macOS yet, even people I’d consider my peers have been struggling with apps suddenly going limp and no indication why. I can only assume it was done, to make it seem like newer OS version were more stable, because hey apps don’t crash any more.
A while ago I had found this lovely bug here: <https://xojo.com/issue/58879> (hard crash when making a date). At the customer it was hard to track down because the app didn’t crash on Catalina. The non-crash behaviour is really really clever. The bug isn’t even reviewed, yet. Sigh…
I wonder if this would work with kexts. I have a driver that is running two of my guys bonkers. The driver works in Big Sur IF the system was upgraded from 10.14 or 10.15. But, if it’s a clean install on a new 11.x system, the launch fails with no kernel or crash output.
