Mi socket actualmente arroja net::ERR_CONNECTION_REFUSED porque el servidor no se está ejecutando, lo que quiero que haga en este momento.
El problema es que el siguiente fragmento de código no detecta el error. En la consola veo una excepción en la línea 2 (con net::ERR_CONNECTION_REFUSED) que creo que no debería ocurrir ya que está dentro de una declaración de prueba.
1 try { 2 ws = new WebSocket('ws://'+ host + ':' + port + '/'); 3 } 4 catch (err) { 5 console.log('This never prints'); 6 } 7 ws.onerror = function (error) { 8 console.log(error); 9 };Entonces mi pregunta es ¿por qué no se detecta?
Lo que finalmente quiero es que el mensaje de error se muestre en otro lugar, pero no puedo captarlo, y la línea 8 imprime un objeto de "evento" que no menciona net::ERR_CONNECTION_REFUSED, por lo que no estoy seguro de cómo obtener el mensaje de error.
El error de tiempo de conexión de WebSocket provoca un evento enviado , no un valor lanzado . Esto se debe a que las operaciones de throw deben ser sincrónicas. Para manejar todos los errores de tiempo de conexión como errores lanzados, el constructor de WebSocket necesitaría suspender por completo toda la ejecución de secuencias de comandos y la interacción de la interfaz de usuario hasta que se haya completado todo el protocolo de enlace de WebSocket. En su lugar, el proceso de conexión se ejecuta de forma asíncrona, lo que permite que el subproceso del navegador continúe funcionando mientras la conexión WebSocket se inicializa en segundo plano. Debido a la naturaleza asíncrona de la conexión, WebSocket debe informar los errores a través de eventos de error , ya que la new WebSocket ya ha finalizado cuando la tarea de conexión asíncrona encuentra un error.
El mensaje ERR_CONNECTION_REFUSED que ve es únicamente para el beneficio de los desarrolladores; no es accesible para el script de ninguna manera. No tiene ninguna representación dentro del entorno de JavaScript. Es solo un mensaje de color rojo que aparece en su consola para informarle a usted , el humano que mira el navegador, sobre un error.
El evento del controlador de error es el lugar correcto para responder a la falla, pero la falta de información de error de tiempo de conexión legible por script es por diseño. De la especificación WHATWG para la API de WebSocket :
Los agentes de usuario no deben transmitir ninguna información de falla a los scripts de una manera que permita que un script distinga las siguientes situaciones:
- Un servidor cuyo nombre de host no se pudo resolver.
- Un servidor al que los paquetes no se pudieron enrutar correctamente.
- Un servidor que rechazó la conexión en el puerto especificado.
- Un servidor que no pudo realizar correctamente un protocolo de enlace TLS (por ejemplo, el certificado del servidor no se puede verificar).
- Un servidor que no completó el protocolo de enlace de apertura (por ejemplo, porque no era un servidor WebSocket).
- Un servidor WebSocket que envió un protocolo de enlace de apertura correcto, pero que especificó opciones que hicieron que el cliente interrumpiera la conexión (por ejemplo, el servidor especificó un subprotocolo que el cliente no ofreció).
- Un servidor WebSocket que cerró abruptamente la conexión después de completar con éxito el protocolo de enlace de apertura.
[...] Permitir que un script distinga estos casos permitiría que un script sondee la red local del usuario en preparación para un ataque.
El navegador está omitiendo deliberadamente cualquier información útil según lo requerido por la especificación. A los autores de la especificación les preocupa que el acceso a esta información pueda permitir que una página web malintencionada obtenga información sobre su red, por lo que requieren que los navegadores informen todos los errores de tiempo de conexión de una manera indistinguible.
Intenté crear un violín con él y puedo ver la línea impresa.
host='localhost'; port=100; try { ws = new WebSocket('ws://'+ host + ':' + port + '/'); } catch (err) { console.log('This never prints'); } ws.onerror = function (error) { console.log(error); };