I think this even more than historical legacy is what prevented
OpenStep from being exception-safe at its introduction in 1994;
after all, it had to run reasonably on 25MHz 68040 hardware with
32MB (or even less) memory.
I´m not sure which CodeWarrior DR variant finally implemented C++
exceptions (DR1 was released in 1/1994), but probably since then the
zero cost handlers were AFAIR state of the art on 68k systems (my copy
of CW ran on a 68030 Powerbook 140)..
Alas, all this is despite exceptions being an established best
practice for safe error propagation and recovery since the mid-1970s
in academia (aka Lisp, Ada and functional languages), and since the
early 1990s in the C++ community [...]
.. Thanks to some outstanding C++ advocates educating developers how
to write really working "rollback" code ;-), basically by splitting
code into atomic units that might succeed or fail ...
Which is really too bad, because pervasive exception-safe code makes
it very easy to cleanly propagate errors across layers of a system
to the point at which it's appropriate to handle them. Instead
right now, if something deep inside your code can return an NSError,
everything between the call that can return the error and your UI
needs to be able to propagate it out. It's the bad old days of
OSErr or HRESULT propagation all over again, where every call has to
be wrapped in an "if" block and every method has to return a result
code that the next layer checks.
I still consider it worse - most of Foundation et al is not
retrofitted to error handling but returns nil and there is no way to
tell the user WHY he really lost data. And most of the existing code
I've seen is written with then same "return nil on error" paradigm in
mind, so there is also no up-propagation of an error state...
