Как правильно сообщить об ошибке клиенту через WebSockets

Чтобы развить те моменты, которые я упомянул, вашу проблему о том, «как обрабатывать требуемый параметр», я вижу следующие варианты. Прежде всего, давайте рассмотрим конечную точку:

@ServerEndpoint(value = "/websocket/myendpoint", 
                configuration = MyWebsocketConfiguration.class)
public class MyEndpoint{
    // @OnOpen, @OnClose, @OnMessage, @OnError...
}

Фильтрация

Первый контакт между клиентом и сервером — это HTTP-запрос. Вы можете отфильтровать его с помощью фильтра, чтобы предотвратить рукопожатие веб-сокета. Фильтр может либо заблокировать запрос, либо пропустить его:

import javax.servlet.Filter;

public class MyEndpointFilter implements Filter{
    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        // nothing for this example
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {

        // if the connection URL is /websocket/myendpoint?parameter=value
        // feel free to dig in what you can get from ServletRequest
        String myToken = request.getParameter("token");

        // if the parameter is mandatory
        if (myToken == null){
            // you can return an HTTP error code like:
            ((HttpServletResponse) response).setStatus(HttpServletResponse.SC_NOT_FOUND);
            return;
        }

        // if the parameter must match an expected value
        if (!isValid(myToken)){
            // process the error like above, you can
            // use the 403 HTTP status code for instance
            return;
        }

        // this part is very important: the filter allows
        // the request to keep going: all green and good to go!
        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {
        //nothing for this example
    }

    private boolean isValid(String token){
         // how your token is checked? put it here
    }
}

Если вы используете фильтр, вы должны добавить его в свой файл web.xml:

<web-app ...>

    <!-- you declare the filter here -->
    <filter>
        <filter-name>myWebsocketFilter</filter-name>
        <filter-class>com.mypackage.MyEndpointFilter </filter-class>
        <async-supported>true</async-supported>
    </filter>
    <!-- then you map your filter to an url pattern. In websocket
         case, it must match the serverendpoint value -->
    <filter-mapping>
        <filter-name>myWebsocketFilter</filter-name>
        <url-pattern>/websocket/myendpoint</url-pattern>
    </filter-mapping>

</web-app>

async-supported был предложен BalusC в моем вопросе для поддержки асинхронной отправки сообщений.

TL, DR

если вам нужно манипулировать параметрами GET, предоставленными клиентом во время подключения, фильтр может быть решением, если вас устраивает чистый ответ HTTP (код состояния 403 и т. д.)

Конфигуратор

Как вы могли заметить, я добавил configuration = MyWebsocketConfiguration.class. Такой класс выглядит так:

public class MyWebsocketConfigurationextends ServerEndpointConfig.Configurator {

    // as the name suggests, we operate here at the handshake level
    // so we can start talking in websocket vocabulary
    @Override
    public void modifyHandshake(ServerEndpointConfig sec, HandshakeRequest request, HandshakeResponse response) {

        // much like ServletRequest, the HandshakeRequest contains
        // all the information provided by the client at connection time
        // a common usage is:
        Map<String, List<String>> parameters = request.getParameterMap();

        // this is not a Map<String, String> to handle situation like
        // URL = /websocket/myendpoint?token=value1&token=value2
        // then the key "token" is bound to the list {"value1", "value2"}
        sec.getUserProperties().put("myFetchedToken", parameters.get("token"));
    }
}

Хорошо, отлично, чем это отличается от фильтра? Большая разница в том, что вы добавляете сюда некоторую информацию в свойствах пользователя во время рукопожатия. Это означает, что @OnOpen может иметь доступ к этой информации:

@ServerEndpoint(value = "/websocket/myendpoint", 
                configuration = MyWebsocketConfiguration.class)
public class MyEndpoint{

     // you can fetch the information added during the
     // handshake via the EndpointConfig
     @OnOpen
     public void onOpen(Session session, EndpointConfig config){
         List<String> token = (List<String>) config.getUserProperties().get("myFetchedToken");

         // now you can manipulate the token:
         if(token.isEmpty()){
             // for example: 
             session.close(new CloseReasons(CloseReason.CloseCodes.CANNOT_ACCEPT, "the token is mandatory!");
         }
     }

    // @OnClose, @OnMessage, @OnError...
}

TL;DR

Вы хотите манипулировать некоторыми параметрами, но обработать возможную ошибку с помощью веб-сокета? Создайте свою собственную конфигурацию.

Попробуйте поймать

Я также упомянул опцию try/catch:

@ServerEndpoint(value = "/websocket/myendpoint")
public class MyEndpoint{

     @OnOpen
     public void onOpen(Session session, EndpointConfig config){

         // by catching the exception and handling yourself
         // here, the @OnError will never be called. 
         try{
             Long token = HTTP.getRequiredLongParameter(session, "token");
             // process your token
         }
         catch(BadRequestException e){
             // as you suggested:
             session.close(new CloseReason(CloseReason.CloseCodes.CANNOT_ACCEPT, "some text"));
         }
     }

    // @OnClose, @OnMessage, @OnError...
}

Надеюсь, это поможет

Я считаю, что должен был поставить...

session.close(new CloseReason(CloseReason.CloseCodes.CANNOT_ACCEPT, "some text"));

... прямо там, где возникает ошибка, в @OnOpen(). (Для общих ошибок используйте CloseCodes.UNEXPECTED_CONDITION.)

Клиент получает:

onClose(1003, some text)

Это, конечно, очевидный ответ. Я думаю, что приведенный пример ввел меня в заблуждение, вызвав исключение из @OnOpen(). Как предположил Реми Лебо, сокет, вероятно, был закрыт из-за этого, блокируя любую дальнейшую обработку с моей стороны в @OnError(). (Возможно, какая-то другая ошибка скрыла обсуждаемые доказательства.)