At 09:49 AM 9/23/99 -0700, you wrote:
>>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?
You kill the app if it lets exceptions out. Not even bothering to return
an error code is akin to saying you don't think anyone that develops for
the platform bothers to check for them.
>
>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.)
>
How about actually giving the developer the chance to fix the problem?
Your whole argument seems to be aimed at defending a poorly chosen behaviour.
I'll bet that none of the OSes you vaguely refer to behave in the same way
as PalmOS - even the one that crashes the OS probably does so because of an
unhandled exception (which OS is this by the way, I would be interested if
you could name it). They probably all give the developer a chance to
correct their error - and funnily enough I'll guess that they tend to
return errors codes in functions that are documented as doing so.
