>The thing you don't get is that the former is only happening because you
>fail to handle the exception that is thrown during the call to memset().
>The proper behaviour is to throw an exception...
Yes, and if an app can't be trusted to not write to null, (or insert your
favorite stupid/fatal bug here) how many of those apps could be trusted to
handle an exception properly?
There's a judgement call involved to determine when is the right time to
forcibly shut down an app which is doing something sufficiently
stupid/dangerous. Every OS does this to some degree - some by crashing the
OS and forcing the user to manually power-cycle it, some by silently
killing a task, some by bringing up dialog boxes of varying degrees of
user-friendliness. (Blue screen of death, sad mac, core dump, etc.)
We totally agree that some of the APIs made this determination too quickly
- the function could and should have just returned an error code. We've
cleaned up quite a few of those cases, both in shipping OS versions and in
future ones. Have we hit them all? Probably not, but that's again a
judgement call.
If the OS just always politely returned an error code and never said
"enough is enough" your risk of losing data, corrupting saved information,
toasting hardware, etc. rises dramatically. Perhaps some hypothetical OS
and programming practices could make this completely safe, but we ain't
there on any commonly used platform that I know of. (There are also cases
where there's no reasonable way to indicate an error because the data is so
wildly wrong/inappropriate, sort of like unanswerable questions like "Have
you stopped beating your wife yet?")
So: we totally agree with the feedback about cutting down on fatal alerts
where there's a reasonable way to return an error value. Got it, we've
done it, and are doing it. But remove all fatal alert calls? That doesn't
seem to be the right thing to do.
-David Fedor
Palm Developer Support
