>It is inexcusable that the documents
>indicate a function returns an error when in fact it generates a fatal
>error dialog.
I totally agree, and (as I've said a few times in this thread already)
we've been actively changing both the OS and the documentation to not do
fatalAlerts in inappropriate situations. And listing specific situations
where the docs and/or OS should in your opinion change is extremely
helpful; my thanks to the folks who've already done so. (Saying "fix
everything!" is a waste of keystrokes...)
I'm not sure if saying it once more will help, but to recap some previous
notes: there are *some* situations where a fatal alert is appropriate, if
things are judged to be badly enough off. That judgement call isn't easy
to pin down precisely. But for example I'd suggest that passing a null
pointer to some routine might generate an error code, but a doing a MemSet
to a garbage nonzero pointer into the middle of the dynamic heap, colliding
with the memory manager structures... well, that provides good reason to
believe that the app is just plain messed up and things need to be stopped
before damage gets done and the situation degrades.
Please don't nitpick the example as an argument that fatals aren't ever
appropriate. Bring the conversation up a level and offer practical ideas
of what you'd say would be grounds for a reset and what wouldn't, given the
existing tools, OS architecture, memory model, and assuming the presence of
bugs in third party apps that could damage user data. That's the way to
help the OS get better, which benefits everyone here.
And please prove my fears wrong that this thread has the potential to
degrade into unhelpful theoretical arguments and hairsplitting! We can do
better than usenet at large...
-David Fedor
Palm Developer Support
