CODEWITHSUNDEEP
business-objects
Neil Knight
Neil Knight

Reputation: 48587

Good/Bad business object design?

I have inherited a suite of business objects, which are working rather well. It looks as though it's based on the CSLA framework by Rockford Lhotka, but there is one very annoying issue. When the business object does a load, it throws an exception. So, if it tries to load some data that isn't available in the database, you get an exception thrown. Is this good design?

Upvotes: 1

Views: 197

Answers (3)

TGardner
TGardner

Reputation: 176

I've been having a debate with a co-worker about this very topic lately.

It's my assertion that a situation where a method you expect to do X does not do X is the very definition of an exception.

What you chose to do with that exception is another story. You can choose to handle it internally in your code or you can choose to defer the handling of that exception to a higher level in your code.

I will agree that it is always better to handle an exception if it at all makes sense to do so when and where it occurs rather than deferring it to a higher level of code.

That said I also believe that in lower levels of code it can make some sense to defer the handling of these exceptions to the higher levels of code. This provides the higher level of code more flexibility in how it wants to handle these situations and it also gives that higher level of code insight into what occured.

If for example your retrieving data from a database and building an object for use in your application you could conceivably have several things happen:

  1. Return an Object as expected.
  2. Be unable to connect to the database.
  3. Not find the data you expect to find.

You could handle the exceptions 2 and 3 by simply returning an empty object or null but then the higher level code doesn't know why the information it requested was not returned. This would require some secondary pattern in which to notify the higher level of what occurred.

Alternatively I assert that you could create a custom exception with a message field in which to pass back the exception event which occurred. Forcing your higher level code to handle those situations as it sees appropriate.

In my opinion the later can be more flexible but does require the higher level code to know it needs to handle the exceptions which should be well documented so that its clear a method can throw certain exceptions.

Note: I am not an expert, I do not claim to be, I am sharing my opinion after encouragement from my peer whom I have been debating this topic with.

Upvotes: 2

The Archetypal Paul
The Archetypal Paul

Reputation: 41779

It depends on the impact to the application of the data being missing. If the application cannot reasonably continue without the data, then it is an exceptional case and an exception is warranted. If it is relatively normal for the data to be missing (and especially if the caller is expected to handle the exception and carry on), then that is a use of exceptions that is a bad design.

Upvotes: 2

Nate
Nate

Reputation: 30656

IMHO, Exceptions are for exceptional cases -- missing data is usually not exceptional, unless its on a primary key, or other non-null field.

Upvotes: 2

Related Questions