0

As I understood, we use Guava Preconditions to fail fast, before changing some objects states (a nice answer here from stackoverflow). And this is good. However it throws Runtime exceptions and this is not the favorite exceptions for the user of an application (500 errors and so on ...). So I need you to give me some help in design.

I have an interface that declares many methods. Each method has arguments which must be controlled (ex: not null). So in the implementation class I use instructions like the following :

Preconditions.checkNotNull(fooObj);

However the program calling this API might crash due to a runtime exception, that is in this case NullPointerException.

So how do you handle these unchecked exceptions?

Thank you.

-------- EDIT The app layers :

  • Data Access Layer

  • API declaring the methods that exchange DTO

  • Process implementing the API and checking arguments using Guava

  • Webservice depending on the process layer

Farah
  • 2,469
  • 5
  • 31
  • 52
  • 1
    A program that throws an exception doesn't crash. It throws an exception. It seems you're writing a web app. This will thus display an error page to the user. You can show whatever you want in this error page. But such an exception shows that your code has a bug. So what you must do, is fix your code, to avoid that bug, and thus avoid that error page to be displayed in the first place. – JB Nizet Oct 27 '17 at 20:17
  • Absolutely, a 500 shows a bug in the code to fix. So at which layer do you think it is the most convenient to handle this exception? For example, in the method that is calling the API that must enforce catching and unchecked exception? – Farah Oct 27 '17 at 20:25
  • You haven't said anything about your app and its layers. I don't know what kind of app it is, what technology it uses, which layers it has. If it's a traditional webapp, it shouldn't be caught at all. Just let it bubble until the web container displays an error page. – JB Nizet Oct 27 '17 at 20:27
  • You're right. Sorry for the inconvenience. See my edit. – Farah Oct 27 '17 at 20:36

2 Answers2

5

A failure of a precondition means that your program has a bug. Users should not encounter these unless they've found a bug in your program.

Your program should in general show some kind of error message to users in case of an error, but more to the point, you should get informed so you can fix the bug in the first place.

Louis Wasserman
  • 191,574
  • 25
  • 345
  • 413
  • Ah! So you mean that the input data had to be rejected at an early stage, right? For exemple, the form that will send a request to the component by doing fields validation? What about for an SOA architecture without GUI? Thanks – Farah Oct 27 '17 at 20:29
  • If you're validating user input, you should not be using `Preconditions`, or runtime exceptions. You should be handling it some other way. – Louis Wasserman Oct 27 '17 at 20:33
2

You handle them by designing your program to ensure they never happen. These precondition methods are intended to detect bugs and help find exactly where the root cause is, not to verify user input.

If you are defining only the API, not the programs that call it, then you "handle" it by telling people in your documentation that the arguments in question must not be null, and leave the problem of satisfying that requirement to them.

If you are writing a calling program as well, first try to make sure the exception just never happens. You can also put the call in a try/catch block to catch the NullPointerException, but the purpose of the catch block should be to give you better notification of the bug (e.g. record a log message or trigger an alert) and the triggering circumstances, and possibly to shut down more gracefully or give a more user friendly error message. Attempting to recover from the failure should be done with great care or not at all - if this kind of failure happens then something has gone wrong that you did not foresee, and the proper way to recover may not be predictable.

Douglas
  • 5,017
  • 1
  • 14
  • 28