What you said makes sense. We should indeed try the best to write solid code. However, what bothers me the most is when an invalid ID is passed, it does not always gives out fatal error and sometimes it gives out "not found" and sometimes fatal error and we pull the hair to figure out what the differences are??
Thanks. Max --- Peter Epstein <[EMAIL PROTECTED]> wrote: > I don't think anyone is debating whether an API that's documented as > returning an error code should in fact do so. The issue is whether APIs > should generally return error codes or not. The fact is that failing to > check the result of an API call is a very common programming error, and in > some cases, not easily detected. The "Writing Solid Code" book discusses > this very issue, and I tend to agree with the author. If it can be argued > that "this should never happen", then returning an error code when it > happens is risky, as the problem is likely to go undetected. > > It's especially nice if expensive error checking can be done only in debug > ROMs, and since the result of the function can't be any different on debug > and release ROMs, the only way to get this improved error checking in debug > ROMs is to present a fatal error on debug ROMs. > > All that said, you may very well have a good reason for calling > DmFindRecordByID with invalid unique IDs. Consider this: An errant program > mistakenly passes in an invalid unique ID and fails to check the result. It > then uses the index to access the record. Can we set the index to a value > that will guarantee a fatal error at this point, or will the error continue > to go undetected? > -- > Peter Epstein > > -- > For information on using the Palm Developer Forums, or to unsubscribe, please > see http://www.palmos.com/dev/tech/support/forums/ __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
