Java - Programando con aserciones preguntas

Question

Me pregunto si mucha gente programa en Java con aserciones. Creo que esto puede ser muy útil en grandes proyectos sin suficientes contratos por escrito o contratos obsoletos. Particularmente cuando utiliza webservices, componentes ...

Pero nunca he visto ningún proyecto que use aserciones (excepto en pruebas junit/testng ...).

Me di cuenta de que la clase lanzada es un error y no una excepción. ¿Puede alguien decirme por qué eligen un error? ¿Puede ser porque una excepción podría ser atrapada inesperadamente y no registrador/reintroducido?

Si desarrolla una aplicación con componentes, me pregunto dónde pone las aserciones: - Del lado de los componentes, justo antes de devolver los datos a través de la API pública? - En el lado del cliente componente? Y si la API se llama en todas partes, ¿configura un patrón de fachada que llamará al mecanismo de aserción? (Entonces supongo que pone sus aserciones y fachada en algún proyecto externo y los proyectos de sus clientes dependerán de este proyecto de afirmación?)

Entiendo cómo usar las aserciones, y cuándo las uso, pero me pregunto si algunas personas tienen recomendaciones basadas en una experiencia real de afirmación.

Gracias

Answer 1

Por cierto, te refieres a assert en Java?

Personalmente encuentro aserciones especialmente útiles para invariantes. Tenga en cuenta que la comprobación de afirmaciones está desactivada de forma predeterminada en java. Debe agregar el indicador -ea para habilitar la verificación de afirmaciones. En otras palabras, puede probar su aplicación en una especie de modo de depuración, donde el programa se detendrá una vez que se rompe una aserción. Por otro lado, la aplicación de lanzamiento tendrá su afirmación desactivada y no incurrirá en penalización de tiempo para la verificación de la afirmación, serán ignoradas.

En Java, las aserciones son mucho menos poderosas que las excepciones y tienen significados totalmente diferentes. Hay excepciones cuando ocurre algo inesperado y tienes que manejarlo. Las afirmaciones se refieren a la corrección de tu código. Están aquí para confirmar que lo que "debería ser" es realmente el caso.

Mi política áspera, especialmente cuando se trabaja con muchos desarrolladores:

• métodos públicos: compruebe siempre argumentos y tirar IllegalArgumentException cuando algo está mal
• métodos privados: utilizar afirmaciones para comprobar argumentos en contra de punteros nulos y por lo tanto en
• métodos complejos: afirmaciones intermedios para garantizar que los resultados intermedios satisfacen propiedades solicitadas

... pero en realidad, los uso espasmódicamente. Justo donde es crítico o lugares propensos a errores.

Answer 2

Sobre el uso menor de las afirmaciones Creo que fue una mala decisión desactivar las aserciones de manera predeterminada.

Acerca de la extensión del error Supongo que amplía el error porque los errores son excepciones que no se espera que sean atrapadas. Y de esa manera, cuando en su código tiene catch (Exception), la aserción no se almacena en caché.

Y sobre el uso, el mejor lugar es en precondiciones, postcondiciones o en el medio del código en cualquier invariante que desee verificar.

Answer 3

En mi opinión, los errores en Java se deben tratar como una excepción. Por lo tanto, habilitaría las afirmaciones en el desarrollo y en los métodos privados para comprobar que mi código se ejecuta correctamente y no pasa valores no válidos a los métodos privados.

Dado que esas comprobaciones deben hacerse en métodos públicos, no volvería a verificar en métodos privados.

Para desactivar afirmaciones:

-da flag in compiler

En mi opinión, en los métodos públicos que usted debe comprobar y gestionar la excepción o registrarlos mismo.

Answer 4

Las afirmaciones no se deben utilizar fuera de las pruebas, ya que se pueden apagar en el entorno de producción, lo que puede causar problemas graves debido a la falta de una comprobación adecuada.

Sin embargo, he visto una declaración de que está permitido usarlos para verificar parámetros en métodos privados, eso es porque asumes que los datos que lograron llegar a tu método privado son correctos y si no es así la aplicación puede fallar.