Excepciones contra códigos de resultado para una clase de cliente de socket

Question

Tengo una clase que encapsula las comunicaciones de socket TCP con un servidor. Para cada mensaje de comando enviado al servidor, el servidor devolverá un mensaje de respuesta que, invariablemente, contiene un código de respuesta (Aceptar, Error). Usando mi clase, cada comando se puede ejecutar ya sea sincronizado o asíncrono.

Hay básicamente dos tipos de excepciones que pueden tener lugar: A " error " esto se debe a un error de desconexión o algún otro error no recuperable y una excepción inesperada como "enviar buffer está lleno". En el caso de una falla, ningún comando puede continuar o volver a intentarlo ni nada hasta que se restablezca la conexión. En el caso de una respuesta fallida o incluso de una excepción, se puede volver a intentar el comando ...

Entonces, ahora mismo, mis métodos de comando de sincronización devuelven una enumeración que puede tener los siguientes valores: OK, Fail, Fault. Si se produce una excepción, simplemente se eleva al subproceso de llamada (en un comando de sincronización). Para los comandos asíncronos, el valor de enumeración de la propiedad Resultado puede contener un valor adicional: OK, Fail, Fault o Exception y la devolución de llamada puede acceder al objeto de excepción real a través de la propiedad Exception del objeto de comando.

¿Qué piensas de esta estrategia? Estoy tentado a no generar excepciones en absoluto para los comandos de sincronización y simplemente registrar la excepción internamente y devolver el cuarto valor de enumeración en su lugar porque eso es todo lo que haré con las excepciones en cualquier caso de todos modos ... O, ¿no debería estar usando? Códigos de resultados y solo plantean excepciones en todos los casos, ¿incluso fallas?

Gracias.

Answer 1

Creo que tu estrategia es básicamente sólida.

Tenga en cuenta que el propósito de las Excepciones es tratar con condiciones excepcionales. Cuanto más cerca de la fuente del problema, mejor.

En su caso, parece que su estrategia es algo así como "no funcionó en este momento". Vamos a volver a intentar " ;. No veo una razón para plantear realmente excepciones.

Si tratar con un socket cerrado era algo que requería un flujo totalmente diferente en su código, tal vez las excepciones tendrían sentido. Según su descripción, ese no es realmente el caso.

Mi filosofía en Excepciones es que deben ser para condiciones excepcionales con las que no puedes lidiar. ¿Un zócalo cerrado? Hmm ... ¿cuántas veces cae internet en mi casa ...

Answer 2

Mi preferencia es que lance una excepción cada vez que su método no complete con éxito su misión. Por lo tanto, si yo, la persona que llama, llamo a yourObject.UploadFile (), asumiré que el archivo se cargó correctamente cuando se devuelve la llamada. Si falla por alguna razón, espero que su objeto arroje una excepción. Si desea distinguir entre los comandos, puedo volver a intentarlo y los comandos que no debería volver a intentar, ponga esa información en la excepción y puedo decidir cómo reaccionar en consecuencia.

Al llamar a yourObject.BeginAsyncUploadFile (), esperaría el mismo comportamiento, excepto que necesitaría esperar en el objeto IAsyncResult o equivalente para averiguar si la carga del archivo se realizó correctamente y luego verificar una Excepción / Error propiedad si no lo hizo.

Answer 3

Los códigos de resultado y las excepciones pueden funcionar bien. Es una cuestión de gusto personal (y del gusto de los demás miembros de su equipo). Las excepciones tienen algunas ventajas, especialmente en configuraciones más complejas, pero en su configuración suena lo suficientemente simple como para que los códigos de retorno funcionen bien.

Algunas personas harán espuma en la boca e insistirán en las excepciones, pero en mi proyecto a la gente le gusta la simplicidad de los códigos de devolución, lo que los convierte en la mejor opción en general.

Answer 4

Esta es una pregunta bastante interesante. Como tal, probablemente no haya una respuesta '100% correcta', y en su mayoría depende de cómo creas que debería estar estructurado el código que utiliza tu función.

La forma en que lo veo es que usa excepciones solo cuando quiere proporcionar el código que llama a su función con una forma de escapar con gracia de una situación "desastrosa". Por lo tanto, en mi código, normalmente lanzo una excepción cuando algo realmente, realmente sucede, y la persona que llama necesita saberlo.

Ahora, si lo que tiene es una situación normal y esperada, probablemente debería devolver un valor de error. De esa manera, el código sabe que necesita "esforzarse más", pero no se verá comprometido por lo que sucedió.

En su caso, por ejemplo, podría tratar los tiempos de espera como algo esperado y, por lo tanto, devolver un código de error y problemas más graves (como un búfer de envío completo) donde el código de llamada necesita realizar algunas acciones adicionales para regresar. a 'normal' como excepción.

Pero entonces, la belleza está en el ojo del espectador, y algunas personas le dirán que solo use excepciones, otras (en su mayoría programadores C) que solo usen códigos de retorno. Solo recuerda, las excepciones deben siempre ser excepcionales. :)