title: How to handle websocket @OnError
body: <p>What's the correct way of handling a websocket error besides logging it?</p>
  <p>Regarding <code>onError()</code>, the Endpoint <a href="http://docs.oracle.com/javaee/7/api/javax/websocket/Endpoint.html#onError%28javax.websocket.Session,%20java.lang.Throwable%29" rel="nofollow noreferrer">documentation</a> states that:</p>
  <blockquote>
  <p>Developers may implement this method when the web socket session
  creates some kind of error that is not modeled in the web socket
  protocol. This may for example be a notification that an incoming
  message is too big to handle, or that the incoming message could not
  be encoded.</p>
  <p>There are a number of categories of exception that this method is
  (currently) defined to handle:</p>
  <ul>
  <li><p>connection problems, for example, a socket failure that occurs before the web socket connection can be formally closed. These are modeled as SessionExceptions</p>
  </li>
  <li><p>runtime errors thrown by developer created message handlers calls.</p>
  </li>
  <li><p>conversion errors encoding incoming messages before any message handler has been called. These are modeled as DecodeExceptions</p>
  </li>
  </ul>
  </blockquote>
  <p>Are all of these types of exceptions fatal, causing the websocket to close?</p>
  <p>Should the <code>onError()</code> method close the websocket (call <code>Session.close()</code>) if an error occurs?</p>
  <p>So far, I assumed that it's my responsibility to cleanly close the session, informing the client about the close reason. This is why my <code>onError()</code> tried invoking <code>session.close()</code> if <code>session.isOpen()</code> returned true, but this caused tomcat (8.0.15) to throw a <code>NullPointerException</code>:</p>
  <pre><code>...
  Caused by: java.lang.NullPointerException
      at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:96)
      at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:81)
      at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:444)
      at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:335)
      at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:264)
      at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:536)
      at org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:464)
      at org.apache.tomcat.websocket.WsSession.close(WsSession.java:441)
      at my.package.MyEndpoint.onWebSocketError(MyEndpoint.java:229)
      ... 18 more
  </code></pre>
  <p>Is this a tomcat bug, a misunderstanding on my part, or both?</p>
  <p><strong>Edit:</strong> It seems that the Java EE websocket example <a href="https://java.net/projects/javaeetutorial/sources/svn/content/trunk/examples/web/websocket/dukeetf2/src/main/java/javaeetutorial/web/dukeetf2/ETFEndpoint.java?rev=1783" rel="nofollow noreferrer">dukeeetf2</a> assumes that errors are fatal; and that there's no need to close the session. The errors are logged, and the session is removed:</p>
  <pre><code>@OnError
  public void error(Session session, Throwable t) {
      /* Remove this connection from the queue */
      queue.remove(session);
      logger.log(Level.INFO, t.toString());
      logger.log(Level.INFO, &quot;Connection error.&quot;);
  }
  </code></pre>