At this point in my career, I can't go back to a language that doesn't have support for Optionals or compiler validation of nullable types. I can sacrifice async or fancy stream apis, but I will never go back to chasing null pointer exceptions on a daily basis.
Obj-C does have a "nonnull" annotation now (apparently added to assist Swift interop). One of the final jigsaw pieces turning it into a really pleasant language.
nonnull doesn't really do anything in pure objc. It warns if you assign the nil literal to a nonnull pointer and that's it. The annotation is almost entirely for the sake of Swift interop (where it determines if the pointer is bridged as an Optional or not).
It is a really pleasant language, but I think the <nonnull> annotation is for initialization only - compiler checking against initializing an object ptr with a null value - and does not prevent crashing when addressing an already released object
I don't think objc has the equivalent of a null pointer exception. You can freely send messages to a deallocated object. Since ARC, it is rare, at least in my experience, running into any memory related issues with objc.
You can send messages to `nil`, but the inverse isn't universally true. APIs like
will throw an `NSInvalidArgumentException` if `other` is nil.You can send messages to null, sendings messages to a deallocated pointer is going to be a bad time.
It’s nice not to crash, but unexpected null can still cause bugs in ObjC when the developer isn’t paying attention.
Having done both ObjC with nonnull annotations, and Swift, I agree that it’d be hard to forgo the having first-class support for Optionals
Objective-C did not have null pointer exceptions, though some libraries added them.
If you use Objective-C objects, operations on null pointers are just a no-op, so there is not such thing as chasing exceptions.