5

I have a very simple servlet, which contains the following code to build a response:

@Override
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
    response.setContentType(CONTENT_TYPE);
    final PrintWriter out = response.getWriter();
    // ...

My Sonar raises a critical issue with the rule: "Exceptions should not be thrown from servlet methods". Sonar explains it's a bad idea to let such exceptions be thrown:

Failure to catch exceptions in a servlet could leave a system in a vulnerable state, possibly resulting in denial-of-service attacks, or the exposure of sensitive information because when a servlet throws an exception, the servlet container typically sends debugging information back to the user. And that information could be very valuable to an attacker.

But if I understand their example, I cannot figure how to manage smartly the potential IOException on response.getWriter().

Some people can explain me when this statement can raise an exception, and how/why it's important to manage it by our-self?

EDIT: I accepted the first answer despite that I was a little frustrated. I understand very well it's a bad practice to let the servlet container manages this exception as the default behavior expose the stacktrace and possible other sensitive information to the world. In my case, the HTTP end-point was used for internal monitoring. So in my case, I wanted to expose (relevant) information and the question was HOW I can do that if I have no PrintWriter...

What I did: my program prints an error log and it returns an HTTP error code with no content. I don't know if it can really happen... but Sonar and me are happy.

mcoolive
  • 3,805
  • 1
  • 27
  • 32
  • 2
    You can either 1) catch it, log it, and serve nothing to the client, or 2) use a filter to catch exceptions that you throw out of request handlers then present something reasonable to the user (example: http://stackoverflow.com/questions/11245932/how-to-handle-exceptions-thrown-while-rendering-a-view-in-spring-mvc). Keep in mind also that Sonar is giving you worst case warnings but can't necessarily judge what's appropriate in your specific scenario. – Jason C Aug 30 '16 at 14:25
  • @JasonC while the link to the other answer is for me a nice answer, I think it is worth keeping on SO the fact that this is a solution to SonarQube warning. (disclaimer : I develop the java analyzer for sonarqube). That is why I think the question should be reopened and not marked as duplicate). – benzonico Aug 31 '16 at 08:45
  • @benzonico The OP pretty clearly asks for best practices managing exceptions thrown in servlets, which is identical to the duplicate and answered well there. The fact that the OP just happened to originally start thinking about it because of some quality management system warning is incidental and pretty irrelevant. How do you think that changes the question? – Jason C Aug 31 '16 at 10:37
  • might be debatable but having on SO a clear link and reference about how to fix a specific SonarQube warning is something valuable for future reader IMO. – benzonico Aug 31 '16 at 11:42

2 Answers2

1

By throwing an exception in a servlet you expose the stacktrace and possible other sensitive information to the world. You should catch the exception and print/show a nice error message.

Nicklas Andersson
  • 44
  • 2
  • 2
    I understand I should return a nice error message to the client. But how can I do that if I can't write in the response object? Again, I don't understand when getWriter can throw an IOException. – mcoolive Aug 30 '16 at 15:28
  • 1
    wrap the getWriter call in an try catch block and in the catch block you can decide what to do in case an exception is thrown. If the getWriter in practice cant throw an exception i this case, due to external factors for example, then you can ignore the warning. – Nicklas Andersson Sep 08 '16 at 08:55
0

It's simple: assume all the consumers your service has are idiots and need to be treated with kid gloves - that means sending them a nicely formatted error message with a description of your choosing instead of the whole Exception.

rorschach
  • 2,871
  • 1
  • 17
  • 20