3 ms·
Not crashing on null is part of what led to the remarkable stability of iPhone apps vs Android. Same with javascript apps. Can you imagine how painful the web
by trixie_ 4y ago
Not crashing on null is part of what led to the remarkable stability of iPhone apps vs Android. Same with javascript apps. Can you imagine how painful the web would be if the entire page 'crashed/disappeared' every time an unhandled exception was hit in javascript.
If programmers today treated software like a car, they would blow up the car every time the air conditioner button didn't work. Desktop and console apps work this way.
Perfect is the enemy of the good, many times your app isn't running a nuclear reactor, and even if it was you might want it actually be able to recover from a failure. Think Erlang.
- hayley-patton 4y ago> Think Erlang. Conventional Erlang style is to crash a lot, but to limit the amount that crashes by using enough processes, I believe, c.f. "The How and Why of Fitting Things Together" <https://www.youtube.com/watch?v=ed7A7r6DBsM&t=1535s https://www.youtube.com/watch?v=ed7A7r6DBsM&t=1535s>. But the key part to handling failure is to detect it first, and silently passing through nil/null/etc is not that.
- trixie_ 4y agoNo matter how you do it, avoiding a hard crash is the point. Don’t throw away the users work because some feature threw an uncaught null exception.