Shall I design the following API using null returned value, or checked exception, or possible null object pattern

Question

I come to an API getStock designed, where I have no good judgment, on how I should deal with failure of operation.

The API will enable me to pass a stock code, and return a stock if success.

Shall I use null returned value to indicate failure of operation, or throwing checked exception to indicate failure of operation? Or possible Null Object Pattern? Why?

Null Returned Value

// User force to check the returned value each time.
// This happen when, stock server is down, network is down, 
// stockCode is not valid...
Stock stock = stockServer.getStock(stockCode);
if (stock != null) {
    // Success.
}

Checked Exception

try {
    // User force to catch the exception each time.
    // This happen when, stock server is down, network is down,
    // stockCode is not valid...
    Stock stock = stockServer.getStock(stockCode);
    // Success.
} catch (StockNotFoundException ex) {
}

Null Object Pattern

Stock stock = stockServer.getStock(stockCode);
// stock.getPrice(), stock.getVolume() will return 0...
// But when there is a need to check whether we are getting
// a null stock, we need to check 
// if (stock.getPrice() == 0.0 && stock.getVolume()...

Go with null. http://www.cs.oberlin.edu/~jwalker/nullObjPattern/ btw, jStock seems impressive. just downloaded it ;) — zengr, Oct 12 '10 at 06:21
possible duplicate of [Return 'null' or throw exception](http://stackoverflow.com/questions/175532/return-null-or-throw-exception) — Stephen C, Oct 12 '10 at 07:11

Charles Salvia · Accepted Answer · 2010-10-12T06:01:50.917

My advice when it comes to this sort of (subjective) design decision is to go with the grain of the language (i.e. try and follow the practices used by the standard library of the language.) The Java standard library usually prefers exceptions for error handling, rather than return values. For example, the Java Socket class throws an IOException if it cannot connect (e.g. if the network is down, or the remote address is invalid).

Null return values, on the other hand, are usually used in cases where, for example, a Collection object is unable to find a specified key.

So I think, in your case, an exception is more "in the spirit" of the Java language, because it could indicate a serious problem such as a network error.

You could also use a null return value to indicate that the specified stockCode does not exist, and an Exception to indicate a more serious problem, such as a down network. Although, this will require users of your API to check for a null return value and handle the exception.

Or can I say, `return null` when there is higher chance for failure. `throw exception` when the chance for failure is lower. — Cheok Yan Cheng, Oct 12 '10 at 06:03

score 3 · Answer 2 · answered Oct 12 '10 at 06:04

3

I would say do a mixture. Throw an exception for errors (stock server is down, network is down, etc) and return null if the code cannot be found. This is consistent with other Java error handling. Collections return null if there is no value associated with the key (not unlike no stock associated with the symbol) and sockets throw exceptions when the network is down. Note: I clearly used the examples from @Charles's answer.

answered Oct 12 '10 at 06:04

Chris Thompson

35,167
12
80
109

But, isn't that will be extremely cumbersome? Caller have to do 2 things. try...catch and check for null. – Cheok Yan Cheng Oct 12 '10 at 06:07
@Yan: Those are two different situations: an expected output and an error situation. Therefore they should be handled differently. – fish Oct 12 '10 at 07:05
@fish I think they are pretty fuzzy and there is no clear cut. For example, I use Socket's connect. I can `expect` a network connection problem. But Java people treat it as exception. – Cheok Yan Cheng Oct 12 '10 at 07:45

score 1 · Answer 3 · edited May 23 '17 at 09:58

1

Duplicate of Return 'null' or throw exception.

As the absence of a stock code is not an error, I suggest not throwing an exception. In order not to test for null all over the place, implementing the null object pattern might be a solution.

edited May 23 '17 at 09:58

Community

1
1

answered Oct 12 '10 at 05:57

zellus

9,617
5
39
56

score 0 · Answer 4 · answered Oct 12 '10 at 05:57

When it is an expected case that the stock you are looking for does not exist, use return null;

If it is really an exception to the normal workflow, use the exception.

Exception handling is really expensive and should only be used to handle an unexpected situation.

hth

Mario

Shall I design the following API using null returned value, or checked exception, or possible null object pattern

4 Answers4