Re:The Compiler Is Your Best Friend, Stop Lying to It
by Krssst on Wednesday December 31, 2025 @04:40PM
(#46448654)
> Your software may gain a reputation of being crash-prone
Hopefully crashing on unexpected state rather than silently running on invalid state leads to more bugs being found and fixed during development and testing and less crash-prone software.
Re:The Compiler Is Your Best Friend, Stop Lying to It
by Calavar on Wednesday December 31, 2025 @05:06PM
(#46448856)
> If a valid alternative is to halt normal operations and present an alert box to the user saying "internal error 573 occurred. please restart the app", then that is much preferred IMO.
You can do this in your panic or terminate handler. It's functionally the same error handling strategy, just with a different veneer painted over the top.
Re:The Compiler Is Your Best Friend, Stop Lying to It
by lmm on Wednesday December 31, 2025 @10:05PM
(#46450905)
Crashing is bad, but silently continuing in a corrupt state is much worse. Better to lose the last few hours of the user's work than corrupt their save permanently, for example.
Re:The Compiler Is Your Best Friend, Stop Lying to It
by saagarjha on Thursday January 01, 2026 @06:55AM
(#46453420)
So you don't get a crash log? No, thanks.
Re:The Compiler Is Your Best Friend, Stop Lying to It
by SAI_Peregrinus on Thursday January 01, 2026 @11:29AM
(#46455339)
- The user may have unsaved data
That should not need to be a consideration. Crashing should restore the state from just before the crash. This isn't the '90s, users shouldn't have to press "save" constantly to avoid losing data.
The problem with this attitude (that many of my co-workers espouse) is that it can have serious consequences for both the user and your business.
- The user may have unsaved data - Your software may gain a reputation of being crash-prone
If a valid alternative is to halt normal operations and present an alert box to the user saying "internal error 573 occurred. please restart the app", then that is much preferred IMO.