Return null or throw throw again

Question

I was already looking for the answer to this question, and I found the following suggestions:

• If you always expect to find a value, then throw an exception if it is missing. An exception will indicate that a problem has occurred. If the value may be absent or present, and both are valid for application logic, then return zero.
• Throw an exception only if it is really a mistake. If the behavior of the object is not expected to exist, return zero.

But how should I interpret them in my (so random) case: My web application controller receives a request to display details for a user with a specific identifier. The controller requests a level of service to get the user, and then the service returns an object if it is found. If not, a redirect to the "default location" is issued.

What if someone passes an invalid user id inside the url? Should I consider it to be "expected behavior" and return null to the controller, or perhaps I should call it "problem or unexpected behavior" and thus throw an exception inside the service method and catch it inside the controller?

Technically, this is not a big difference, but I would like to do it right by following the standard tips. Thanks in advance for any suggestions.

EDIT: I assume that the URLs generated by the application are valid and existing - when clicked by the user, the user should find the certaing identifier. I want to know how to handle a situation where a user tries to access a URL with an invalid (non-existent) user ID by manually entering the URL into the address bar of the browser.

Answer 1

If you understand correctly, the request containing the user ID comes from the client (out of your control). Applying the rules of thumb that you specified: invalid user input is a quite expected case that does not require an exception, rather it handles a null value gracefully, returning the appropriate error message to the client.

(OTOH, if the user ID in the request was automatically generated by another application / from the database, etc., an invalid user ID would be unexpected, so an exception would be appropriate.)

Answer 2

My personal suggestion is to register error data (IP address, invalid user ID) and redirect the user to the error page, which says that an error has occurred, and the administrators have been notified. Click the so-n-so link to return to the homepage, etc.

Point, whether you throw an exception or return null , just make sure that the external filter or handler "logs" the details before the response is returned to the user.

Answer 3

 What should I do when someone passes invalid user id inside the request URL? 

You have two options: show the "default" page that you mentioned, or return "Not Found" / 404.

Regarding the null value, this depends. If you find null unacceptable for a link, then annotate it with @NotNull , and the annotation should take care to do the right thing when getting the null link: that is, throw a (unchecked) exception (of course, you need to work with the wonderful @NotNull annotation for this to make it work).

What you do up the chain depends on you: they return me 404 to someone who is trying to fake the sounds of user identifiers that are really close to optimal.