Software will save us

interface TagReader {
    Tag readTag(File file, URI tagURI);
}

I think returning null would be the best way to do it. It's fast, can be documented just as well as throwing an exception (If you have Intellisense, you can see the notes on it faster than checking the code for what exceptions it throws), and like you said, in any case every caller has to deal with the results one way or the other.

Throwing an exception is a costly event, and in such numbers, i'm pretty sure you'll be seeing some heavy overhead due to them.

Returning a Null object seems to be problematic, since then the callers have to check for the Null object that you provided, and not a generic null. If i were using that framework, it would certainly surprise me to get an object that was all empty, i would have thought that it's a bug.

Ah, classic problem! Let us know when you've made a decision, and why :)

Good luck! In your case I really don't know which one is the worst :)

Josh Bloch (a famous software architect) as some opinion about null here
(chap "Being Forgiving")

If you chose the null solution don't forget to add coments in your javadoc about return value...
Since your the "dictator" I would say "do as you'd like it to be"

To decide, you could (just to decide) write 3 methodes:
- readTagNull
- readTagException
- readTagNullObject
and write the unit tests that goes with them.

Then you would see what it looks like to be the user of your own classes and in the "boundary cases" which one need less code to write or has cleaner code on the client side.

Personally, of those three choices I'd return null. But then, I don't subscribe to the "nulls are bad" theory.

The Null Object offers no noticeable advantages over returning null in this case.

A fourth possibility is to return an Array or a List of all of the TagS, rather than one at a time. A variant would be to return a Iterator (or Enumeration). That's how I would do it: create a File.getTagIterator(URI tagURI) method that returns an Iterator. And scratch the TagReader interface entirely.

My thinking goes that an exception, while it has some benefits, is the worst choice. And once you leave that out, returning a null object seems bizarre for this use case. I do think nulls are bad in some cases, but I’m with Doug on this one, particularly his Array/Iterator suggestion.

What you really want is to offer the caller is a way to treat the “no such tag” case exactly the same as the “tag found” case, unless the caller is explicitly interested. By giving the caller a list of some form, this becomes possible: a list is a list is a list, whether it has 0 elements or 42.

If you were writing the code in a language with first-class lists (such as most dynamic ones) this approach would probably have been obvious.

The answer depends on what a Tag actually is. OK it's a class, but what are its members and functions, so what does it actually do?

This is important, since there may be a fourth solution: Return an empty Tag instance. As you would do when returning an instance of a string class, for example. This is somehow similar to the Null Object but not quite the same.

Second, the correct solution depends on the use cases you want to serve. It seems you want to retrieve known tags from known files, which looks like there is already some knowledge about the file's tags at this point. If so, retrieving a tag that doesn't exist is more or less unlikely - speak exceptional. So throwing an exception may be the right thing to do.

If, however, tags are retrieved using some kind of trial and error - you test all known tags against a file -, a less costly way of indicating no result would be better. As a C++ programmer I tend to just return the null pointer NULL, which represents "no instance" - and that's what we have here. So it seems the natural thing to do.

However, returning a list of all tags of a file and continue working on this is way better, as Aristotle already mentioned.

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

URL:
Remember me? YesNo

Comment (no HTML, URLs will be auto-linked):