Yes, I think that maybe those issues are just cosmetics but anyway I like to analyze whether I want or not to have an Exception thrown in the method I am creating.

Sometimes protecting for nulls does more harm than good. Sometimes it masks errors that should be thrown.

Well, well maybe that’s just “much ado about nothing”

null is not a valid name so throwing an exception is ok,
it makes the code more english-like: “if the username is the one we are looking for” rather than “if the username we are looking for is the name of the user”.

At this point we’re discussing cosmetics!

“Anyway, like I said, it’s *NOT* a major problem”

However, I disagree that using multiple return increases the difficulty to maintain and the content/complexity of a procedure. What I found is that even in complex code, the return statement makes it clear because when another user is evaluating the code and reaches for a return statement it doesn’t goes on with the evaluation thinking about something like “oh! there was an if up there so this else is evaluated when…”.

Anyway, like I said, it’s a major problem

On the opposite, using too many return statment might break the control flow of an app, increase the difficulty to maintain..By using mutliploe return statment, people usually tend to increase the content of a single procedure, and so the complexity. The worst is when an app duplicate some lines of code because there is several entry point….

My recommendation is the following:
- try to maintain a single return statment
- unless it create “more ” (and this the difficulty) complexity than several return

So in other word, keep the single return as a recommendation, but not as an obligation…..

Regarding your question:

You are right, getAllUsers() shouldn’t return a null item at all. And
better yet, if getAllUsers() has a null user, it is desirable that a
NullPointerException is thrown there. I wrote the null check without
thinking about it

Regarding that code, there is an additional tip that I don’t know if
you know yet.

Notice that in my code I wrote:

if (u != null && name.equals(u.getName())) {
return true;
}

Taking off the “u != null” part, I have used name.equals(u.getName()).
This is a suberb protection for users with null name. Notice that the
“name” parameter is not likely to be null, so you are better off
doing:

name.equals(u.getName())

than

u.getName().equals(name)

because if u.getName() is null, the first comparation will return
false and the second will raise an exception.

Hope this helps you somehow and thanks again for your comments on my
post. That’s what make posting on a blog worth.

Best regards,