Warnings? Both?), make errors not so damn expensive and fix @ to be much
more lean-and-mean than it is now.
Kill it could be an option too. I see the need of @ as a design failure.
Is ICU an indication of how this should be handled as well. Being able to
switch exceptions off in intl demonstrates that they may not be necessary.
a library which is built around supporting exceptions can work, but currently we
have a bunch of code (both in the core and in userland), which doesn't support that.
errors can support the execution of the execution, which means allowing to have
return values, or emiting multiple errors from the same call, with exceptions
you can't do that, as the execution will jump to the next catch block (or to the
global exception handler).
I don't think I have seen any proposal so far which would solve these issues,
yet people still talking about like replacing the current error handling
infrastructure with exceptions would be a viable alternative.
While the discussion has also been opened up to include C++ which use 'exceptions' in normal process flow, IS it a given that we have to have exceptions at all? To my mind proper error handling should prevent the 'white screen' as the only way of handing things when everything has gone tits up? :(