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".
as a user, i am very happy that the OS halts buggy apps.
as a developer, i am even happier, since some of these APIs do things like
fill in an out parameter with an index. now, if the calling app does not
expect an error return, and doesn't bother to handle, or even handles it
incorrectly, then the app may very well end up trying to use the bogus index
that was passed back, and may end up damaging another record.
----- Original Message -----
From: Richard Hartman <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 22, 1999 4:31 PM
Subject: RE: C++ SDK wanted!
>
> > -----Original Message-----
> > From: Chris Antos [mailto:[EMAIL PROTECTED]]
> >
> > > Give us the standard function names where applicable, "strcat"
> > > instead of "StrCat", "memset" instead of "MemSet", etc.
> ...
> > seems like a waste to have Palm address this particular one instead of
> > spending the time on some more critical issue such as unique ids.
>
> Well, now that it's been done, perhaps ... but wasn't
> it quite a waste of their time to come up with this alternate
> set of functions in the first place?
>
> > > 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...)
> >
> > you mean the ones that are documented to return a particular
> > code but reset
> > anyway, right? it's common knowledge that "there's still a
> > couple broken
> > APIs", but does anyone know which APIs are still broken? all
> > the ones i use
> > are fine.
> >
> > in general it's very good for users that the OS forces a
> > reset instead of
> > letting the buggy app continue to run.
>
> Not if the documentation says it returns an error code.
>
> If they want a system function to crash & burn if anything
> goes wrong instead of sending a code back to the caller to
> handle as the caller deems appropriate, at the very least they
> should be documented that way:
>
> this function dies a horrible flaming death if
> anything goes wrong.
>
> better still: an OS-level flag for "protection level".
>
> If the program doesn't want to take responsibility for
> protection, let the OS put up the reset dialogs when
> things go wrong, but if the app -does- want to handle
> things differently, it should have the option to do so.
>
> --
> -Richard M. Hartman
> [EMAIL PROTECTED]
>
> 186,000 mi./sec ... not just a good idea, it's the LAW!
>
