¿Por qué muchos mensajes de excepción no contienen detalles útiles?


220

Parece que hay cierto acuerdo en que los mensajes de excepción deben contener detalles útiles .

¿Por qué es que muchas excepciones comunes de los componentes del sistema no contienen detalles útiles?

Algunos ejemplos:

  • El Listacceso al índice .NET ArgumentOutOfRangeExceptionno me dice el valor del índice que se intentó y no era válido, ni me dice el rango permitido.
  • Básicamente, todos los mensajes de excepción de la biblioteca estándar MSVC C ++ son completamente inútiles (en la misma línea que arriba).
  • Excepciones de Oracle en .NET, que le dicen (parafraseado) "TABLA O VISTA no encontrada", pero no cuál .

Entonces, para mí parece que, en su mayor parte, los mensajes de excepción no contienen detalles suficientes para ser útiles. ¿Están mis expectativas fuera de línea? ¿Estoy usando excepciones equivocadas que incluso me doy cuenta de esto? O tal vez mi impresión es incorrecto: la mayoría de las excepciones no realmente ofrecen detalles útiles?


59
Cabe señalar que, desde el punto de vista de los profesionales de seguridad, "los mensajes de error no deben contener detalles sobre los componentes internos del sistema" es una regla general.
Telastyn

118
@Telastyn: solo si su sistema está abierto a los atacantes. Si está ejecutando un servidor web, por ejemplo, desea enviar mensajes de error insípidos al usuario final, pero aún desea que se registren mensajes de error muy detallados a su finalización. Y en el software del lado del cliente, donde el usuario no es un atacante, definitivamente desea que esos mensajes de error sean lo más detallados posible, de modo que cuando algo salga mal y reciba un informe de error, tenga tanta información para trabajar como sea posible, porque muchas veces eso es todo lo que obtienes.
Mason Wheeler

99
@Snowman: ¿Qué es inaccesible para el usuario si es un software del lado del cliente? El propietario de la máquina es el propietario de la máquina y puede acceder a cualquier cosa.
Mason Wheeler


66
Siempre hay información adicional que le gustaría tener. Creo que los mensajes que da como ejemplos son bastante buenos. Puedes depurar el problema con ellos. Mucho mejor que el "error 0x80001234" (ejemplo inspirado en Windows Update).
usr

Respuestas:


204

Las excepciones no contienen detalles útiles porque el concepto de excepciones aún no ha madurado lo suficiente dentro de la disciplina de ingeniería de software, por lo que muchos programadores no las entienden completamente y, por lo tanto, no las tratan adecuadamente.

Sí, IndexOutOfRangeExceptiondebe contener el índice preciso que estaba fuera del rango, así como el rango que era válido en el momento en que se lanzó, y es despreciable en nombre de los creadores del tiempo de ejecución de .NET que no lo hace. Sí, la table or view not foundexcepción de Oracle debe contener el nombre de la tabla o vista que no se encontró, y nuevamente, el hecho de que no lo haga es despreciable en nombre de quien sea responsable de esto.

En gran parte, la confusión se deriva de la idea original equivocada de que las excepciones deben contener mensajes legibles por los humanos, lo que a su vez se debe a la falta de comprensión de qué se tratan las excepciones, por lo que es un círculo vicioso.

Dado que las personas piensan que la excepción debe contener un mensaje legible por humanos, creen que cualquier información que contenga la excepción también debe formatearse en el mensaje legible por humanos, y luego se aburren de escribir todo el mensaje legible por humanos. código de construcción, o tienen miedo de que hacerlo pueda estar divulgando una cantidad de información desaconsejable a los ojos curiosos que puedan ver el mensaje. (Los problemas de seguridad mencionados por otras respuestas).

Pero la verdad del asunto es que no deberían preocuparse por eso porque la excepción no debe contener un mensaje legible por humanos. Las excepciones son cosas que solo los programadores deberían ver y / o tratar. Si alguna vez es necesario presentar información de fallas a un usuario, debe hacerlo a un nivel muy alto, de manera sofisticada y en el idioma del usuario, que, estadísticamente hablando, es poco probable que sea inglés.

Entonces, para nosotros los programadores, el "mensaje" de la excepción es el nombre de la clase de la excepción , y cualquier otra información pertinente a la excepción debe copiarse en las variables miembro (final / solo lectura) del objeto de excepción. Preferiblemente, cada pequeño fragmento concebible. De esta manera, no es necesario (o debería) generar un mensaje, y por lo tanto, ningún ojo curioso puede verlo.

Para abordar la preocupación expresada por Thomas Owens en un comentario a continuación:

Sí, por supuesto, en algún nivel, se va a crear un mensaje de registro con respecto a la excepción. Pero ya ve el problema con lo que está diciendo: por un lado, un mensaje de registro de excepción sin un seguimiento de pila es inútil, pero por otro lado, no desea permitir que el usuario vea el seguimiento completo de la pila de excepción. Nuevamente, nuestro problema aquí es que nuestra perspectiva está sesgada por las prácticas tradicionales. Los archivos de registro han estado tradicionalmente en texto plano, lo que puede haber estado bien mientras nuestra disciplina estaba en su infancia, pero tal vez ya no: si existe un problema de seguridad, entonces el archivo de registro debe ser binario y / o encriptado.

Ya sea texto binario o simple, el archivo de registro debe considerarse como una secuencia en la que la aplicación serializa la información de depuración. Tal flujo sería solo para los ojos de los programadores, y la tarea de generar información de depuración para una excepción debería ser tan simple como serializar la excepción en el flujo de registro de depuración. De esta manera, al mirar el registro puede ver el nombre de la clase de excepción (que, como ya he dicho, es para todos los propósitos prácticos "el mensaje"), cada una de las variables miembro de excepción que describen todo lo pertinente. y-práctico-para-incluir-en-un-registro, y todo el seguimiento de la pila. Observe cómo el formato de un mensaje de excepción legible por humanos falta notablemente en este proceso.

PD

Algunos de mis pensamientos sobre este tema se pueden encontrar en esta respuesta: Cómo escribir un buen mensaje de excepción

PPS

Parece que una gran cantidad de personas estaban siendo enumeró por mi sugerencia acerca de los archivos de registro binario, por lo que modificó la respuesta una vez más para que sea aún más claro que lo que estoy sugiriendo aquí es no que el archivo de registro debe ser binarios, pero eso el archivo de registro puede ser binario, si es necesario.


44
He revisado algunas de las clases de excepción en .NET Framework, y resulta que hay muchas oportunidades para agregar este tipo de información mediante programación. Así que supongo que la pregunta se resuelve "por qué no lo hacen". Pero +1 para toda la cosa "legible por humanos".
Robert Harvey

77
No estoy de acuerdo con que las excepciones no deberían contener un componente legible por humanos. En algún nivel, es posible que desee crear un mensaje de registro con respecto a la excepción. Yo diría que registrar un seguimiento de pila en un archivo de registro legible por el usuario está exponiendo detalles de implementación que no desea exponer, por lo que el mensaje legible por humanos debería registrarse. Cuando se les presenta el archivo de registro que contiene el error, los desarrolladores deben tener un punto de partida para comenzar su depuración y poder forzar la excepción. El componente legible por humanos debe detallarse adecuadamente sin revelar la implementación.
Thomas Owens

44
¿Entonces los programadores no son humanos? Mirando a mis colegas, esto confirma algunas sospechas que he tenido por algún tiempo ...
gbjbaanb

51
Nuevamente, no hay nada de malo en permitir que el usuario vea todo el seguimiento de la pila , siempre que el software esté del lado del cliente. Todos los proyectos de software profesional en los que he trabajado, y la mayoría de los aficionados también, contenían un sistema de registro que generaría un volcado de error completo cuando se generaba una excepción no controlada, incluidas las trazas completas de todos los subprocesos que se ejecutan actualmente en el proceso. Y el usuario podría (¡jadeo, oh horror!) Mirarlo en cualquier momento que quisiera, ya que eso es necesario (no simplemente útil, sino obligatorio ) para enviarnos el mensaje de error. ¿Qué hay de malo con eso?
Mason Wheeler

13
Tampoco estoy convencido con respecto a los archivos de registro binarios solamente . Principalmente por mi experiencia con systemd. Su herramienta especial para ver estos registros es bastante confusa y parece haber sido diseñada por un comité de monos de Shakespeare. Tenga en cuenta que, para una aplicación web, la primera persona en ver su excepción a menudo será el administrador del sistema , y querrá determinar si es algo que necesita arreglar (por ejemplo, el disco se quedó sin espacio) o regresar a los desarrolladores.
Michael Hampton

46

¿Por qué es que muchas excepciones comunes de los componentes del sistema no contienen detalles útiles?

En mi experiencia, hay una serie de razones por las cuales las excepciones no contienen información útil. Espero que este tipo de razones también se apliquen a los componentes del sistema, pero no estoy seguro.

  • Las personas centradas en la seguridad ven las excepciones como una fuente de fuga de información (por ejemplo ). Dado que el comportamiento predeterminado de las excepciones es mostrar esa información al usuario, los programadores a veces se equivocan por precaución.
  • En C ++, he escuchado argumentos en contra de la asignación de memoria en bloques catch (donde al menos parte del contexto para hacer buenos mensajes reside). Esa asignación es difícil de administrar y, lo que es peor, puede causar una excepción de falta de memoria allí, a menudo bloqueando su aplicación o perdiendo memoria. Es difícil formatear bien las excepciones sin asignar memoria, y esa práctica puede haber migrado entre lenguajes como lo hacen los programadores.
  • Ellos no lo saben Es decir, no son escenarios en los que el código tiene ninguna idea de lo que salió mal. Si el código no lo sabe, no puede decírtelo.
  • He trabajado en lugares donde las preocupaciones de localización impidieron poner cadenas de inglés solamente en el sistema, incluso para excepciones que solo serían leídas por el personal de apoyo que habla inglés.
  • En algunos lugares, he visto excepciones que se usan más como afirmaciones. Están allí para proporcionar un mensaje claro y fuerte durante el desarrollo de que algo no se ha hecho o que se ha hecho un cambio en un lugar, pero no en otro. Estos suelen ser lo suficientemente únicos como para que un buen mensaje sea un esfuerzo duplicado o simplemente confuso.
  • La gente es perezosa, programadores más que la mayoría. Pasamos mucho menos tiempo en el camino excepcional que en el camino feliz, y este es un efecto secundario.

¿Están mis expectativas fuera de línea? ¿Estoy usando Excepciones erróneas que incluso me doy cuenta de esto?

Un poco? Quiero decir, las excepciones deberían tener buenos mensajes, pero también son excepciones . Debería pasar su tiempo diseñando código para evitar condiciones excepcionales, o escribiendo código para manejar condiciones excepcionales (ignorando el mensaje), no usándolos como una especie de mecanismo interactivo de retroalimentación al codificar. Es inevitable usarlos con fines de depuración, pero en la mayoría de las situaciones se debe mantener al mínimo. Que te des cuenta de este problema me preocupa que no estés haciendo un buen trabajo para prevenirlos.


Soy consciente de que esto se ha etiquetado como C, pero debo agregar que su último párrafo no se aplica a todos los idiomas, ya que algunos pueden (de manera correcta o incorrecta) depender en gran medida de la gestión de errores y los informes basados ​​en excepciones .
Lilienthal

1
@Lilienthal - como? Ningún lenguaje con el que estoy muy familiarizado hace ese tipo de cosas regularmente.
Telastyn

1
Creo que esta respuesta tiene mucho contenido bueno, pero evita decir el resultado final, que es "Deberían".
djechlin

3
Gracias. Su preocupación es infundada (espero :-). Pero cada vez que paso un minuto extra rastreando lo que salió mal en esa Prueba de Unidad o paso tiempo adicional analizando el código porque el archivo de registro carece de información, estoy un poco molesto por la basura evitable de algunos mensajes :-)
Martin Ba

El ABAP patentado de @Telastyn SAP tiene una construcción de clase de excepción que puede contener un mensaje, que es básicamente un objeto específicamente destinado a informar el estado del programa (éxito, falla, advertencia) al usuario junto con un mensaje dinámico (multilingüe). Admito que no sé qué tan extendido es este tipo de cosas, o si incluso se fomenta en los idiomas si es posible, pero hay al menos uno donde es (lamentablemente) una práctica común.
Lilienthal

12

No tengo un exceso de experiencia en C #, o C ++ específicamente, pero puedo decirte esto: las excepciones escritas por el desarrollador 9 de cada 10 veces son más útiles que cualquier excepción genérica que puedas encontrar, punto.

Idealmente, sí, una excepción genérica le indicará exactamente por qué ocurrió el error y podrá solucionarlo con facilidad, pero de manera realista, en aplicaciones grandes con múltiples clases que pueden generar una amplia variedad de diferentes tipos de excepciones, o Con el mismo tipo de excepciones, siempre es más valioso escribir su propia salida para la devolución de errores que confiar en el mensaje predeterminado.

Así es como debe ser, porque como muchas personas han señalado, algunas aplicaciones no quieren lanzar un mensaje de error que no quieren que el usuario vea, por razones de seguridad o para evitar confundirlos.

En su lugar, debe anticipar en su diseño qué tipos de errores pueden aparecer en su aplicación (y siempre habrá errores) y escribir mensajes de detección de errores que lo ayuden a identificar el problema.

Esto no siempre lo ayudará, porque no siempre puede anticipar qué mensaje de error será útil, pero es el primer paso para comprender mejor su propia aplicación a largo plazo.


7

La pregunta es específicamente por qué tantas excepciones lanzadas por "componentes del sistema" (también conocidas como clases de biblioteca estándar) no contienen detalles útiles.

Desafortunadamente, la mayoría de los desarrolladores no escriben los componentes principales en las bibliotecas estándar, ni los documentos de diseño detallados u otra razón de diseño necesariamente se hacen públicos. En otras palabras, es posible que nunca lo sepamos con certeza.

Sin embargo, hay dos puntos clave a tener en cuenta en cuanto a por qué la información de excepción detallada podría no ser deseable o importante:

  1. Se puede usar una excepción llamando al código de cualquier manera: una biblioteca estándar no puede imponer restricciones sobre cómo se usa la excepción. Específicamente, se puede mostrar al usuario. Considere un índice de matriz fuera de límites: esto puede proporcionar información útil a un atacante. El diseñador de idiomas no tiene idea de cómo una aplicación usará la excepción lanzada o incluso qué tipo de aplicación es (por ejemplo, aplicación web o escritorio), por lo que omitir información puede ser más seguro desde una perspectiva de seguridad.

  2. No se deben mostrar excepciones al usuario. En su lugar, muestre un mensaje de error descriptivo y registre la excepción en una ubicación a la que el atacante no tenga acceso (si corresponde). Una vez que se identifica el error, un desarrollador debe depurar el código, inspeccionando los marcos de pila y las rutas lógicas. En este punto, el desarrollador tiene más información de la que una excepción podría esperar tener.


3
1. Basado en este criterio, parece relativamente arbitrario qué información es ("Índice fuera de rango", seguimiento de pila) y no se muestra (valor del índice). 2. La depuración puede ser mucho más rápida y fácil cuando se conocen valores dinámicos relevantes. Por ejemplo, a menudo le dirá de inmediato si el problema es la entrada de basura en el código que falló, o si el código no trata correctamente con una buena entrada
Ben Aaronson

@BenAaronson, la identidad / clase de la excepción nos dice el tipo de error. Mi punto es que los detalles podrían omitirse (es decir, qué valor específico causó el error) por seguridad. Ese valor puede rastrearse hasta la entrada del usuario, revelando información a un atacante.

@Snowman No creo que la seguridad sea una consideración cuando hay disponible un seguimiento completo de la pila y el número de índice no. Claro que entiendo a un atacante que analiza los desbordamientos del búfer, pero muchas excepciones también
omiten

@gbjbaanb, ¿quién dice que necesitamos mostrar el seguimiento completo de la pila al usuario?

1
Gracias por compartir esa idea. Personalmente, no estoy de acuerdo y creo que el argumento de seguridad es una falacia completa, pero puede ser una razón.
Martin Ba

4

En primer lugar, permítanme reventar una burbuja diciendo que incluso si el mensaje de diagnóstico está cargado con información que lo lleva a la línea de código y al subcomando exactos en 4 segundos, es probable que los usuarios nunca lo escriban ni lo transmitan a la gente de soporte y se le dirá "Bueno, dijo algo sobre una violación ... ¡No sé si parecía complicado!"

Llevo más de 30 años escribiendo software y respaldando los resultados de otros programas, y personalmente, la calidad actual de un mensaje de excepción no tiene prácticamente nada que ver con la seguridad, independientemente de cómo los resultados finales se ajustan a su modelo de el universo, mucho más que ver con el hecho de que muchos en nuestra industria fueron originalmente autodidactas, y simplemente nunca incluyeron lecciones en comunicaciones. Tal vez si FORZAMOS a todos los codificadores nuevos a una posición de mantenimiento durante un par de años donde tuvieron que lidiar con la resolución de lo que salió mal, comprenderían la importancia de al menos alguna forma de precisión.

Recientemente, en una aplicación que se está reconstruyendo, se tomó la decisión de que los códigos de retorno caigan en uno de tres grupos:

  • 0 a 9 sería el éxito a través del éxito con información adicional.
  • 10 a 99 serían errores no fatales (recuperables), y
  • 101 a 255 serían errores fatales.

(100 por alguna razón quedó fuera)

En cualquier flujo de trabajo en particular, nuestro pensamiento se reutilizó o el código genérico usaría retornos genéricos (> 199) para errores fatales, dejándonos con 100 errores fatales posibles para un flujo de trabajo. Con datos ligeramente diferenciales en el mensaje, errores como el archivo no encontrado podrían usar el mismo código y diferenciarse con los mensajes.

Cuando el código regresó de los contratistas, no creería nuestra sorpresa cuando prácticamente CADA ERROR FATAL SOLO fue el código de retorno 101.

Todo lo que consideró, creo que la respuesta a su pregunta es que los mensajes no tienen sentido porque cuando se crearon originalmente, debían ser marcadores de posición a los que nadie volvía. Finalmente, la gente descubrió cómo solucionar los problemas no por los mensajes, sino por DISPITARLOS.

Desde ese momento, la gente autodidacta simplemente nunca tuvo un buen ejemplo de lo que debería contener una excepción. Agregue a eso que más usuarios no leen los mensajes, y mucho menos tratan de pasarlo al soporte (he visto mensajes de error que fueron cortados y pegados por el usuario que luego fueron redactados antes de ser enviados con el comentario posterior de que Parecía una gran cantidad de información y no podía quererla toda, por lo que eliminaron al azar un montón de ella.

Y seamos sinceros, con demasiados (no todos pero demasiados) de la próxima generación de codificadores, si es más trabajo y no agrega flash, simplemente no vale la pena ...

Última nota: si un mensaje de error incluye un error / código de retorno, me parece que en algún lugar de los módulos ejecutados debería haber una línea que diga algo así como "si la condición devuelve el valor-código" y la condición debería decirle por qué el código de retorno ocurrió. Esto parece un enfoque lógico simple, pero para mi vida, solo INTENTE hacer que Microsoft le diga qué sucedió cuando una actualización de Windows falló en el CÓDIGO 80241013 o algún otro identificador único. Un poco triste, ¿no?


8
"... no creerías nuestra sorpresa cuando prácticamente CADA ERROR FATAL SOLO fue el código de retorno 101." Tienes razón. No creo que te hayas sorprendido cuando el contratista siguió tus instrucciones.
Odalrick

3
chances are the users will never write it down... and you will be told "Well it said something about a violation..." Es por eso que utiliza una herramienta de registro de excepciones para generar automáticamente el informe de error que contiene el seguimiento de la pila y posiblemente incluso enviarlo a su servidor. Una vez tuve un usuario que no era muy técnico. Cada vez que enviaba un mensaje del registrador de errores, decía algo como "No estoy seguro de qué hice mal, pero ...", no importa cuántas veces le expliqué que este error significaba que el error estaba de mi lado . ¡Pero siempre recibí los informes de error de ella!
Mason Wheeler

3

Si bien estoy de acuerdo en que las excepciones deben contener tanta información como sea posible, o al menos ser menos genéricas. En el caso de la tabla no encontrada, el nombre de la tabla sería bueno.

Pero sabe más sobre lo que estaba tratando de hacer en el lugar del código donde recibió la excepción. Si bien a menudo no puede hacer mucho para rectificar la situación cuando algo sale mal en una biblioteca fuera de su control, puede agregar mucha más información útil sobre en qué situación algo salió mal.

En el caso de la tabla no encontrada, no le ayudará mucho si le dicen que la tabla que no se puede encontrar se llama ESTUDIANTES, porque no tiene una tabla de ese tipo, y esa cadena no está en ninguna parte de su código.

Pero si detecta la excepción y la vuelve a lanzar con la instrucción SQL que intentaba ejecutar, será mejor, ya que resulta que intentó insertar un registro con el campo de nombre Robert '); ESTUDIANTES DE TABLA DE GOTA; (¡Siempre hay un xkcd!)

Por lo tanto, para combatir las excepciones menos informativas: trate de atrapar y volver a lanzar con más información específica de lo que estaba tratando de hacer.

Probablemente debería agregar, para que esto sea más una respuesta al por qué en la pregunta, que una razón probable por la que los creadores de las bibliotecas no se han centrado en mejorar los mensajes de excepción es que no saben por qué se intentó algo que falló, esa lógica está en el código de llamada.


por ejemplo, en C ++ deberías usar throw_with_nestedmucho.
Miles Rout

3

Para dar una respuesta ligeramente diferente: El código ofensivo probablemente se haya hecho para especificar:

  • La función recibe X y devuelve Y
  • Si X no es válido, lanza la excepción Z

Agregue la presión para cumplir exactamente con las especificaciones (por temor a ser rechazado en la revisión / prueba) en un tiempo mínimo y con un mínimo de alboroto, entonces tiene su receta para una excepción de biblioteca totalmente compatible e inútil.


3

Las excepciones tienen un costo específico de idioma e implementación.

Por ejemplo, se requieren excepciones de C ++ para destruir todos los datos vivos entre lanzar un marco de llamada y capturar un marco de llamada, y eso es costoso. Por lo tanto, los programadores no desean utilizar muchas excepciones.

En Ocaml, el lanzamiento de excepciones es casi tan rápido como una C setjmp(su costo no depende de la cantidad de tramas de llamadas atravesadas), por lo que los desarrolladores pueden usarlo mucho (incluso para casos no excepcionales, muy comunes). Por el contrario, las excepciones de C ++ son lo suficientemente pesadas, por lo que probablemente no las usará mucho como lo haría en Ocaml.

Un ejemplo típico es una búsqueda o exploración recursiva que puede "detenerse" dentro de una recursión bastante profunda (por ejemplo, encontrar una hoja en un árbol o una función de unificación). En algunos idiomas es más rápido (por lo tanto, más idiomático) propagar esa condición a cada persona que llama. En otros idiomas, lanzar una excepción es más rápido.

Entonces, dependiendo del idioma (y los hábitos de los desarrolladores que lo usan), una excepción podría llevar muchos detalles útiles o, por el contrario, usarse como un salto rápido no local y llevar solo los datos muy útiles.


66
"Por ejemplo, se requieren excepciones de C ++ para destruir todos los datos vivos entre lanzar un marco de llamada y capturar un marco de llamada, y eso es costoso. Por lo tanto, los programadores no desean usar muchas excepciones". Mierda total. La principal fortaleza de las excepciones de C ++ es que los destructores se llaman determinísticamente. Nadie los usaría si simplemente saltaran.
Miles Rout

Lo sé, pero es un hecho que las excepciones de C ++ no son como Ocaml, y no las usas como lo haces en Ocaml.
Basile Starynkevitch

55
No utiliza excepciones de C ++ para el flujo de control en C ++ principalmente porque hacerlo hace que el código sea ilegible y difícil de entender.
Miles Rout

-2

¿Qué te hace pensar que el valor del índice o el rango requerido o el nombre de la tabla es un detalle útil, por una excepción?

Las excepciones no son un mecanismo de manejo de errores; Son un mecanismo de recuperación .

El punto de excepciones es aumentar hasta el nivel de código que puede manejar la excepción. Donde sea que esté ese nivel, tiene la información necesaria o no es relevante. Si hay información que necesita, pero no tiene acceso inmediato , no está manejando la excepción en el nivel apropiado.

La única vez que puedo pensar en dónde podría ser útil la información adicional es en el nivel superior absoluto de su aplicación, donde se bloquea y emite un volcado de error; pero no es el trabajo de la excepción acceder, compilar y almacenar esta información.

No estoy diciendo que puedas poner "lanzar una nueva Excepción" en todas partes y llamarlo bueno, es posible escribir malas excepciones. Pero incluir información irrelevante no es necesario para usarlos correctamente.


No describiría el nombre de la tabla de la base de datos que falta como irrelevante, aunque entiendo y simpatizo con el punto que está haciendo. Te he dado un voto positivo.
Daniel Hollinrake

1
@DanielHollinrake Sí, el nombre de la tabla es definitivamente el menos irrelevante de los ejemplos. En el código con el que trabajo, este tipo de problema es deprimentemente común y observar cómo se ha maltratado el nombre de la tabla da pistas sobre lo que está mal. He estado tratando de pensar en un ejemplo de por qué estas cosas son irrelevantes para la excepción; tal vez pueda usar esto ...
Odalrick

Estoy en desacuerdo. Para manejar una excepción, es posible que no se requieran detalles adicionales porque solo desea proteger la aplicación de fallas, pero finalmente tendrá que decir por qué no funcionó y poder solucionarlo. Si no tiene ninguna pista, pero el tipo de excepción, entonces depuración de buen aspecto.
t3chb0t

@ t3chb0t Para eso está el seguimiento de la pila y la clase de la excepción y el volcado de memoria y todo lo demás. ¿Cómo sería ayudar a que si un cliente llama y dice: "El equipo me dice que que intentó acceder el índice 5 y que no estaba allí.". Solo podría ayudar si también serializa la lista, y el contexto de la lista y cualquier otra cosa que pueda ser útil. No debe serializar todo el estado de la aplicación cada vez que lanza una excepción.
Odalrick

@Odalrick para el cliente podría no tener ningún sentido, sino como un desarrollador que valorar todas las informaciones que puedo conseguir ;-) entonces tal vez otro ejemplo: Supongamos que un SqlExeption ocurre y eso es todo lo que sabes ... Es mucho más fácil de reparar que si sabe qué cadena de conexión o base de datos o tabla, etc. no funcionó ... y esto es aún más importante si su aplicación utiliza varias bases de datos. Un seguimiento detallado de la pila requiere que se envíen archivos pdb con la aplicación ... no siempre es posible. Además, los volcados de memoria pueden ser muy grandes y no siempre se pueden transferir.
t3chb0t
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.