images - oracle java swing

¿Usas afirmaciones? (16)

Esta no es realmente una "pregunta", así que la estoy haciendo CW.

los

assert

Palabra clave es genial!

Debería hacer que se sienta más seguro con el código que escribió, pero hasta hoy, cuando estaba creando una pequeña clase de prueba (<20 líneas), me doy cuenta de que nunca la uso desde que se introdujo.

¡Infierno! Apenas uso el registrador, lo cual es muy útil, pero no lo fue hasta hoy, pero me doy cuenta de que no uso aserciones.

¿Usas afirmaciones? Si no, ¿cuál es la razón?

¡Sí! ¡Siempre! ¡La palabra clave es mi mejor amigo en todos los idiomas!

No hay una razón real para no usar aserciones, aseguran que las suposiciones básicas que hago sobre los valores y estados de entrada se mantienen.

Si una afirmación falla, significa que debo volver a evaluar mis suposiciones y actualizar el código para manejar nuevas entradas exóticas en las que no pensé al escribir la revisión actual. ¿Qué es lo que no me gusta de eso?

Como es habitual en la programación, es una herramienta que es potente solo cuando se usa correctamente.

El único uso real de las aseveraciones después de la introducción de la prueba unitaria es comunicar el invariante de un método a otros programadores. Y es mucho mejor hacer esto en código real que en comentarios que ignorarán de todos modos. ¡Es difícil ignorar una afirmación!

La palabra clave de assert de Java es bastante half assed (es necesario ejecutar el programa con la opción de línea de comandos -ea), por lo que me encuentro confiando en las excepciones en lugar de en las aserciones.

Me enseñaron a usar muchas afirmaciones en los años 90 y tenían mucho sentido. Es una buena codificación defensiva.

Sin embargo, creo que ahora esto ha sido superado por pruebas de unidad que en realidad obligan a que se ejecute el código y le indica dónde está roto. Las declaraciones de depuración requerían que alguien ejecutara realmente el código de depuración y observara la interfaz de usuario o los registros. Las pruebas unitarias pueden automatizar esto.

No, no los uso.

Me enseñaron que las afirmaciones no deberían usarse en el código de ''producción'', y antes de comenzar a usar algo que debo eliminar de todos modos, de acuerdo con lo que he aprendido, me quedo con la excepción para validar las condiciones.

No, nunca los uses. No sé por qué, simplemente nunca se metió en el hábito.

No. Pero no puedo esperar. Solía hacer pruebas de unidad con junit, pero eso era la escuela, los proyectos pequeños no tenían presión. Estoy en la vida real ahora, se supone que debo terminar este código ayer ...

Nunca solía usarlos, pero pasé un tiempo horrible depurando mi último programa, y en un momento dado estaba registrando cuando las variables eran nulas o no contenían los valores que yo esperaría. Una vez que puse todo en funcionamiento, afirmé todo lo que mi programa necesitaba para ejecutarse correctamente.

Respuesta corta - si.

Respuesta larga: no siempre, pero con bastante frecuencia. Usualmente uso aserciones para los errores que sé que no puedo hacer nada al respecto (mientras el programa se está ejecutando) y el registro no es realmente necesario. Por ejemplo, si tengo que comprobar si un determinado valor está fuera de los límites o si un puntero es NULL aunque debería tener algún valor.

Para otras cosas como "Archivos de análisis" y "No se pudo encontrar el archivo", generalmente hago excepciones. De esa manera puedo registrar el error y usar algún método / archivo a prueba de fallas en su lugar.

Y estoy de acuerdo con Falaina, realmente deberías hacer un punto para notar: "¡Eh! Estoy haciendo algunas suposiciones aquí"

Sí, uso afirmaciones todo el tiempo, básicamente cuando estoy asumiendo que:

Se puede comprobar con un predicado bastante simple.
Obviamente, no es verdad simplemente por leer el código cercano.

Sin embargo, para las afirmaciones que probablemente tengan un impacto insignificante en el rendimiento, uso la función de enforce en la biblioteca estándar del lenguaje de programación D en lugar de assert . Básicamente, esto hace lo mismo que assert excepto que permanece en modo de liberación. Para afirmaciones más costosas, uso assert , que está separado de las compilaciones de modo de lanzamiento.

Si te gustan las afirmaciones, te encantarán los contratos. Básicamente son la idea de afirmaciones que se extienden a más situaciones.

Tiendo a no usarlos, aunque tampoco estoy seguro de por qué.

Si realiza pruebas de unidad, como con nUnit, obviamente las usará todo el tiempo para verificar los resultados de las pruebas.

Tiendo a verificar las condiciones de error y lanzar excepciones en su lugar. La razón es que quiero que siempre se verifiquen estas condiciones, incluso en producción, y las excepciones permiten un manejo más fácil de la condición fallida en lugar de aseveraciones.

Uso aserciones para asegurarme de no introducir errores en mi código. Si sé que un valor debe estar en un mapa, lo afirmo (utilizando la palabra clave assert). Si sé que un parámetro nunca debe ser nulo, lo afirmo. Si sé que el parámetro puede ser nulo, lo verificaré y lanzaré la excepción correspondiente.

Lo leí en Code Complete o Effective Java - las aserciones deben usarse para detectar errores de programación - las excepciones deben usarse para manejar situaciones excepcionales pero posibles. No necesita verificar si hay nulo en todos los métodos de su código si sabe que el valor no será nulo (como se define en un contrato), pero no está de más afirmar si un valor no es nulo. Las aserciones solo están habilitadas si especifica el parámetro -ea a la VM y no deberían afectar el rendimiento de su aplicación si está deshabilitada.

Deberías usar más registro también :-). Aprenda cuándo usar el rastreo, la depuración y la información, y asegúrese de registrar todo lo que hace su aplicación. Hace la vida más fácil cuando tienes que descubrir por qué algo no funciona en un entorno de producción.

Yo los uso todo el tiempo. Son una buena forma de practicar la filosofía "Crash early", es mejor tener que resolver por qué falló una afirmación que tener que lidiar con una salida dañada / dañada.

El problema es que tienes que convertirlo en un hábito. Rara vez veo un término medio en él, las personas no están acostumbradas a ello y casi nunca las usan o las personas las usan y están llenas de basura rigurosamente en todo el código. Solo tiene que entrar en la mentalidad de darse cuenta de que "Oh, hey, estoy implicado asumiendo algo aquí, déjame confirmarlo explícitamente ''afirmar (ASUNCIÓN)''"

Yo no los uso. Las pruebas unitarias deben ser suficientes para probar su código. Además, como están deshabilitados de forma predeterminada, normalmente se ignoran por completo de todos modos. Luego, simplemente tienden a saturar su código con afirmaciones inútiles que podrían expresarse mejor como comentarios.

Sin embargo, si realmente necesita esto, algunas bibliotecas tienen métodos estáticos de aserción a los que puede llamar que no se omitirán. Estos también son mucho más legibles, porque la palabra clave de aserción es poco común e inmediatamente puede causar un momento "wtf", pero Los métodos .x son solo métodos que pueden rastrearse. El framework Spring, en particular, utiliza una biblioteca de aserción.