Fog Creek Software
Discussion Board




record not found error - error?

kinda philosophical question: how do you handle / interpret a record not found in a business-object?

let's say:
GetBook(ISDN = 1984-666-111-777)

do you count it as a bug? basically you assume the record is in the db but in reality it's not. so its an error.

do you count it as a normal thing => user search for a book which has invalid id (so it's not a bug, because the function correctly identified that there is no such a book).

should we use exception? what is the exception here? a search with no result?

na
Thursday, March 13, 2003

If the assumption is valid that the book your're looking for is always there, then I would raise an EBookNotFound exception with the ISBN as a parameter. If the ISBN number was entered by a user or otherwise not guaranteed to be there, it can be expected that some books will not be found, and depending on your language and programming style, you might choose not to raise an exception.

Inspired by the runtime library of my favorite language, I would call it GetBook in the first case where an exception is raised in case the book doesn't exist, and FindBook in the latter case, and use a return value to indicate whether it was there or not.

It's really a matter of style, but this seems to work pretty well.

Big B
Thursday, March 13, 2003

Do you intend to validate the ISBN number format, length etc.

If so, as part of that process, do you intend to check that it is a valid number, possibly using Big B's FindBook method?

I know absolutely nothing about ISBN numbers. Can they be validated using an algorithm (like a credit card number) ? Of course this only tells you if the number is valid, not that it exists in the database.

I agree about it being an exception, rather than an error (assumptions made).

Justin
Thursday, March 13, 2003

Sorry, I got distracted while writing that and forgot you were only using books as an example.

:(

Justin
Thursday, March 13, 2003

I agree with Big B - it depends on the context.

I would say your Getxxx function should return a status or return code

Found  / Not found (or even a null object)

An real error would be something unexpected ie type mismatch, connection lost etc.

Low-level data routines do not have enough business rules to determine if a missing record is a fatal error or not.

It would be up to the calling object to determine if it is a problem or not.

DJ
Thursday, March 13, 2003

All depends on what you advertise as your assumptions.  If your GetRecord assumes that the record will always be there, then you should document it as such, and then also provide the caller with a FindRecord method so the assumption can be checked prior to the call to GetRecord.  If the caller invokes GetRecord without checking the assumption and the record is not found, then that is an exception - the caller violated your assumptions.

If you decide that GetRecord should not assume the record will always be there, then you should return null or a NullObject (see: http://www.cs.oberlin.edu/~jwalker/nullObjPattern/) to indicate that no record corresponding to the key was found.

My personal preference is for the latter design because it introduces less overhead, but purists probably would lean toward the former since GetRecord could not be used as a proxy FindRecord method by callers.

anon
Friday, March 14, 2003

It depends, if this is part of a collection, then do whatever your language does naturally.

IIRC VB throws a bad parameter error if an item isn't in a collection, but VC++ expects the caller to check result code.

However in .NET the system.Collections.SortedList.Item property returns nothing if it's not found.

We did all of this a while ago in VB adding a wrapper layer around a more traditional ISAM database. So we had stuff like:

Set ThisCust=Thing.Customers("BILL")
do while (ThisCust is Nothing)=false
  ThisCust.DoStuff
  Set ThisCust=ThisCust.NextCustomer
loop

The initial set would fail as per VB via an exception but the next customer property was much more friendly and would return nothing. You could use "for each" but then you never get a chance to set the initial start point so we needed a simple iterate function.

Peter Ibbotson
Friday, March 14, 2003

*  Recent Topics

*  Fog Creek Home