> > > All the places in the API that are supposed to return
> > > error codes but instead pop up their own "reset" dialog.
> > > (I think that some, but not all, of these have been
> > > addressed already...)
> hm. so if the OS detects that the calling app has a bug, then the OS
is
> supposed to trust the app to cleanly handle the error? "fool me once,
> shame on you. fool me twice, shame on me".
Looks like we get into a philosophical argument here.
IMHO, an OS API function should NEVER display any user interaction
dialog.
Do you remember any C library function that does a fprintf(stderr)? Or a
Windows API function that pops up a MessageBox() in an error case? Or a
Java API class that displays a JOptionPane.showMessageDialog()?
And why would it be better for the user to have the app crash with a
fatal error requiring a reset (which frightens many users to death!)
instead of giving the application a chance to handle the problem more
gracefully?
My favorite example is DmQueryRecord() which I would suppose to return
NULL if the record, for whatever reason, is not available. (Isn't this
what "query" means?)
Only the latest version of the docs mention that it will popup a fatal
dialog if the index is out of bounds or the record has been deleted
(that is, the record still exists in the database header, but the actual
record chunk is gone).
Another good example is FrmGetObjectIndex which I would very much like
to use for testing if a certain object exists on the current form.
Instead, it pops up an annoying "Object not in form" error (which is,
BTW, not documented).
Grepping the 3.0 PalmOS sources reveals hundreds of
ErrFatalDisplayIf()s. Having to program around these makes life as a
Palm developer much harder than it should be.
Andreas
