Re: Making failed NSAsserts crash an app
On Aug 27, 2009, at 10:27 PM, Joar Wingfors j...@joar.com wrote: Terminology aside, I think that he accurately describes how the Cocoa provided assertion macros are implemented and used in general. These macros allow the developer to describe things that always must be true, and ensures that a failure prevents execution from continuing beyond that point. Used like this, the biggest upshot of turning them off is saving a few CPU cycles, but you will at the same time expose the end user to undefined state and behavior of your application and rob yourself of well defined failure points that assists in troubleshooting. As I said before, I think that using assertions this way makes you use them less. If assertions crash your released program, you will only want to assert when you're about to do something bad like corrupt the user's data. If you can accurately predict that, then why bother with the assert at all? But since assertions exist because no programmer is perfect at determining when an error will occur, you'll wind up missing some bad case. For reference, the UNIX assert() calls abort() at the end. If you have NDEBUG defined (Traditional UNIX release flag) the assert is a no-op. :) --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
RE: Making failed NSAsserts crash an app
Thank you both for the info so far. However, do you have any idea how to accomplish what I actually want to do? Is my original idea of forcing asserts to crash maybe bad, which is why noone even thought of suggesting a way to do it? How do people normally do it? Do they just make a crash reporter framework catch an exception like Rob suggested? What crash reporter framework would you recommend? Just some general info on this and related things, for a newbie who wants hand out his simple app for some other people to use, would be appreciated. You could raise exceptions instead of generating assertion failures. Exceptions are caught by several of the crash reporting frameworks. You could probably map the NSAssert macros to exception-generation code for your beta builds. The NSAssert macros raise exceptions by default in debug builds. --. _ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Making failed NSAsserts crash an app
On Thu, Aug 27, 2009 at 9:46 AM, Squ Airesqu...@live.com wrote: However, do you have any idea how to accomplish what I actually want to do? Is my original idea of forcing asserts to crash maybe bad, which is why noone even thought of suggesting a way to do it? It's a bad idea. Assertions should be optimized out of your release build. Making assertions visible crashes to your users discourages you from writing assertions and discourages users who have to deal with crashes. If they are debug-only issues, you can safely write tons of assertions and only deal with those that have user-visible effects. This is what we do with OBASSERT and friends (in OmniBase.framework, part of the OmniSource library found at http://www.omnigroup.com/developer/ ). --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Making failed NSAsserts crash an app
On Aug 27, 2009, at 3:12 PM, Kyle Sluder wrote: On Thu, Aug 27, 2009 at 9:46 AM, Squ Airesqu...@live.com wrote: However, do you have any idea how to accomplish what I actually want to do? Is my original idea of forcing asserts to crash maybe bad, which is why noone even thought of suggesting a way to do it? It's a bad idea. Assertions should be optimized out of your release build. IMHO This attitude is, at best, a perversion of the very definition of an assertion. Assertions are things that must be true, that is why they are assertions. They do not, check that, should not become less true just because your app is built release vs debug. Making assertions visible crashes to your users discourages you from writing assertions and discourages users who have to deal with crashes. If they are debug-only issues, you can safely write tons of assertions and only deal with those that have user-visible effects. If you are using assertions to test for things that are handleable situations or recoverable errors, you are doing it wrong. Checking is good, but its just that, checking... not asserting. Developers should definitely do both, not overload checks into some type of cuckolded assertion. /IMHO -Ed smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Making failed NSAsserts crash an app
On Thu, Aug 27, 2009 at 12:29 PM, Ed Wynnear...@phasic.com wrote: This attitude is, at best, a perversion of the very definition of an assertion. Assertions are things that must be true, that is why they are assertions. They do not, check that, should not become less true just because your app is built release vs debug. Strictly speaking I believe you're more accurately describing an invariant than an assertion. If you are using assertions to test for things that are handleable situations or recoverable errors, you are doing it wrong. Checking is good, but its just that, checking... not asserting. There's a difference between a condition that will cause your app to crash and a condition that will cause your app to perform extra work/graphics glitch/other easily fixed state. Obviously these latter cases are not desirable, but they're not crashers. Not all error states are fatal states. Assert happens when entering an error state, and is left out of release. abort() happens when entering a fatal state, and is kept in release (hopefully to never be executed). (Just for the record, these opinions are mine and do not necessarily reflect those of my employer. If you want to see how we use OBASSERT and friends, grab the OmniSource frameworks and look at the code.) --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Making failed NSAsserts crash an app
They do not, check that, should not become less true just because your app is built release vs debug. Strictly speaking I believe you're more accurately describing an invariant than an assertion. Not all error states are fatal states. Assert happens when entering an error state, and is left out of release. abort() happens when entering a fatal state, and is kept in release (hopefully to never be executed). Instead of debating the meaning of assertion we should discuss the specific implementation of Cocoa 'assertions', as found in the NSException header. As observed by inspection they call methods on NSAssertionHandler which are documented to raise an exception. If you are using assertions to test for things that are handleable situations or recoverable errors, you are doing it wrong. Checking is good, but its just that, checking... not asserting. There's a difference between a condition that will cause your app to crash and a condition that will cause your app to perform extra work/graphics glitch/other easily fixed state. Obviously these latter cases are not desirable, but they're not crashers. On the basis of an exception causing your application to crash the NSAssert family of assertions should only be used as shorthand for throwing an NSException and in the situations where that is appropriate. I'm pretty sure the reasons for throwing an exception have been discussed on the list before and can be found in the archives. So, How can I guarantee that a failed NSAssert will crash my application? Depending on where you fail an assertion (which will throw an exception) either the uncaught exception handler or the NSApplication handler will be called. NSExceptions that originate on the main thread are caught by NSApplication and printed to the system log. NSExceptions that occur elsewhere are caught by the uncaught exception handler and will crash your application. You can manipulate the uncaught exception handler using NSSetUncaughtExceptionHandler. If you want to do something other than simply log main thread exceptions you can capture them by overriding -[NSApplication reportException:] in a subclass or category. This is illustrated in the cocoadev wiki http://www.cocoadev.com/index.pl?StackTraces As you've duly noted NSAssert/NSException are for programmer error, you've either done something wrong or received an unsuitable input. Make sure to use NSError as appropriate too. Keith ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Making failed NSAsserts crash an app
Hello Kyle, I would beg to differ: On 27 aug 2009, at 13.23, Kyle Sluder wrote: Strictly speaking I believe you're more accurately describing an invariant than an assertion. Terminology aside, I think that he accurately describes how the Cocoa provided assertion macros are implemented and used in general. These macros allow the developer to describe things that always must be true, and ensures that a failure prevents execution from continuing beyond that point. Used like this, the biggest upshot of turning them off is saving a few CPU cycles, but you will at the same time expose the end user to undefined state and behavior of your application and rob yourself of well defined failure points that assists in troubleshooting. Not all error states are fatal states. Assert happens when entering an error state, and is left out of release. abort() happens when entering a fatal state, and is kept in release (hopefully to never be executed). For reference, the UNIX assert() calls abort() at the end. Best, j o a r ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Making failed NSAsserts crash an app
I am planning on using one of the nice crash reporter code/frameworks that are available on the internet that allow me to do stuff that I have seen in many Mac apps. Namely, to allow the user to more easily send me a crash log (plus some user comments on what the user was doing when the app crashed) the next time he launched an app after the crash. Since I absolutely want some information on whenever my NSAsserts fail (because they should NEVER fail and I want to know about it if they do! (at least during beta testing!)), my question is: How can I guarantee that a failed NSAssert will crash my application? I want it to happen in such a way that the next time the user loads the app, the info about the failed NSAssert (perhaps the 2nd description string argument I supply to it, or even the line of code and code file) will go along with the crash reports. How can can I accomplish this? Actually, since I have never worried about this crash log stuff until now, and I'm getting a bit nervous about implementing this correctly for production, I'd just like to ask, is there anything I need to configure for this to work? Do the Cocoa frameworks or Mac OS X itself automatically take care of producing those crash logs and putting them into the ~/Library/Logs folder (that the crash reporter framework can then go ahead and put into the UI)? Or is there anything I have to do myself to make the mechanism work? A final, not 100% related but still related question: Will doing a simple NSLog show up in the crash log in that ~/Library/Logs folder? Or is it only shown in the Console utility? Just to avoid confusion, regard this as an unrelated question not connected to what I've written above. _ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Making failed NSAsserts crash an app
On 27/08/2009, at 7:49 AM, Squ Aire wrote: Since I absolutely want some information on whenever my NSAsserts fail (because they should NEVER fail and I want to know about it if they do! (at least during beta testing!)), my question is: How can I guarantee that a failed NSAssert will crash my application? I want it to happen in such a way that the next time the user loads the app, the info about the failed NSAssert (perhaps the 2nd description string argument I supply to it, or even the line of code and code file) will go along with the crash reports. You could raise exceptions instead of generating assertion failures. Exceptions are caught by several of the crash reporting frameworks. You could probably map the NSAssert macros to exception-generation code for your beta builds. -- Rob Keniger ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Making failed NSAsserts crash an app
On 27/08/2009, at 10:00 AM, Rob Keniger wrote: You could raise exceptions instead of generating assertion failures. Exceptions are caught by several of the crash reporting frameworks. You could probably map the NSAssert macros to exception-generation code for your beta builds. The NSAssert macros raise exceptions by default in debug builds. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
