que - jframe en java

¿Por qué no podemos usar la afirmación para los métodos públicos?

Question

¿Por qué no podemos usar la afirmación para los métodos públicos?

He leído en alguna parte

"Un asertivo no es apropiado en los métodos públicos porque el método garantiza que siempre aplicará las comprobaciones de argumentos. Un método público debe verificar sus argumentos si las aserciones están habilitadas o no. Además, la construcción asertiva no produce una excepción del tipo especificado. Solo puede lanzar un AssertionError ".

Entonces, ¿no es aplicable para el método privado también?
No entendí la declaración anterior claramente

Answer 1

Cualquiera puede llamar a los métodos públicos y no hay control sobre lo que se puede pasar como valores de argumento.

Si supongamos que en el método público hemos validado los valores de argumento de entrada utilizando aserciones, existe la posibilidad de que estas verificaciones (validaciones) no se realicen (o ejecuten) si las aserciones están deshabilitadas y obtendríamos resultados no deseados del método de ejecución. Para evitar resultados indeseables, no deberíamos usar aserciones para validar los valores de argumentos de métodos públicos.

Ahora, la pregunta que puede surgir en su mente es ¿por qué usar aserciones para validar los valores de argumentos de métodos privados?

Bueno, la razón es que los métodos privados pueden llamarse desde la clase que está definida (ya sea desde el método de instancia o desde el método principal estático). El desarrollador de la clase de hecho sabe todo acerca del método privado: qué hace, cómo llámelo y qué valores de parámetros se deben pasar. Por lo tanto, los valores de los argumentos de métodos privados se pueden validar de manera segura mediante aserciones.

Answer 2

Doy una respuesta que no está exactamente en el punto. Por supuesto que puedes usar aseverar en métodos públicos (o donde quieras).

El punto es más sobre lo que debe hacer o no. Yo mismo comprendo perfectamente la respuesta de otras personas sobre cuándo debe o no debe usar la afirmación.

Pero debo admitir que NUNCA uso aserciones, y que rara vez veo aseveraciones en el código. Trabajé solo por unos pocos años, pero en las 4 compañías totalmente diferentes para las que trabajé, no hubo afirmaciones en el código. Ya sea la aplicación web de más de 10 millones de líneas para reservar vuelos, un centro de control de naves espaciales, un software para administrar un hipermercado o un rastreador de errores. Ninguno de ellos usó afirmaciones. Todas las empresas tenían diferentes necesidades y métodos. Ninguno utiliza afirmaciones.

Para mí la razón es simple. La gente aquí dice que las afirmaciones son para la depuración. Esta bien. Y que puedes desactivarlas para mejorar la velocidad. Eso también está bien ... Al principio. Cuanto más complejo sea el programa, más tiempo pasará la depuración. Y algunos errores, incluso con una cobertura de código del 100%, incluso con una amplia integración y pruebas de validación, los encontrará solo en producción. Simplemente porque tus usuarios terminan usando tu aplicación más que tú. Y no lo usarán de la misma manera que tú.

Es gracioso porque en los registros de producción, seguimos viendo stacktraces de código como este:

catch (MyException e) {
logger.war("This should never happen",e);
}

Lo que eso significa es que nunca se sabe lo que podría ocurrir en la producción.

Y que si tienes la oportunidad de hacer un cheque, hazlo. Por supuesto, el comentario de registro es más divertido que útil aquí y sería mejor dejar emerger la excepción.

En todos los casos, no lo convierta en una afirmación que se deshabilitará en la producción. Porque será inútil. Haz que sea código normal que genere una excepción. Asegúrese de que se registra si es apropiado. Asegúrese de que se mostrará un error en la interfaz de usuario. Y asegúrese de poder obtener la excepción y los registros para investigar.

Lo que es importante es que, un día u otro, algún usuario hará cosas que hagan emerger la advertencia. Ya sea por un código mal escrito o algo así, lo verás. Y eso significa que, en lugar de pasar 2 días descubriendo por qué demonios el programa tiene este extraño comportamiento, podrá utilizar el seguimiento de pila completo en un punto de partida y corregir el problema en 2 horas.

Un cheque con una aserción deshabilitada es lo mismo que ningún cheque. Es un código que debe escribir, leer y mantener ... Para nada. Entiendo todo el argumento de rendimiento donde las afirmaciones en la producción ralentizan las cosas. Sí, en algunos casos, hay un problema de rendimiento. En la mayoría de los casos, no ganarás casi nada y perderás preciosos consejos.

Answer 3

En general parece sonido. Aunque hay alguna ocasión en la que esto podría ser útil.

Tenga en cuenta que podríamos querer realizar una operación de database update para un elemento que sabemos que existe. Entonces podría ser útil ver si la rutina tuvo éxito, por ejemplo:

public void update(Object o) {
int nUpdatedObjects = dao.update(o);
assert(nUpdatedObjects == 1)
}

En este caso, sirve para validate la capa dao utilizando el principio de falla rápida .

Answer 4

Esta es probablemente la fuente original, de la guía de Java SE "Programación con aserciones".

No use aserciones para verificar los parámetros de un método público. Una afirmación es inapropiada porque el método garantiza que siempre aplicará las comprobaciones de argumentos. Debe verificar sus argumentos si las aserciones están habilitadas o no. Además, la construcción assert no lanza una excepción del tipo especificado. Solo puede lanzar un error de aserción.

Esto no proscribe las afirmaciones en los métodos públicos. Sólo los proscribe para verificar los argumentos del método público.

Las aseveraciones prueban invariantes. Una clase controla los argumentos reales enviados a sus métodos privados y puede garantizar invariantes. Una clase no controla los argumentos reales enviados a los métodos públicos y debería lanzar excepciones si se violan las condiciones previas, incluso si las aserciones están desactivadas.

Más detalles sobre cuándo usar aserciones están here .

Answer 5

Esta prohibición solo se aplica a las interfaces públicas.

De http://download.oracle.com/javase/6/docs/technotes/guides/language/assert.html#preconditions :

Por convención, las condiciones previas de los métodos públicos se aplican mediante comprobaciones explícitas que generan excepciones específicas y específicas.

Básicamente, la convención es que las interfaces públicas garantizan garantizar las condiciones previas y lanzar excepciones específicas en lugar de AssertionError.

Para todos los demás casos, las afirmaciones son muy valiosas y son una piedra angular para la "programación por contrato". Vea http://java.sun.com/developer/technicalArticles/JavaLP/assertions para una buena introducción.

1. Java ha desactivado las excepciones por una razón: hay muchas fallas catastróficas que generalmente no deberían detectarse. Cualquier asignación de memoria puede lanzar OutOfMemoryError. Una afirmación fallida (un error en el código del cliente que proporcionó un argumento no válido a nuestra API) no es menos catastrófica.

2. Es cierto que las aserciones pueden ser desactivadas. Sin embargo, esto nunca debería hacerse. Solo no lo hagas. Si está preocupado de que alguien que esté ejecutando su código desactive las aserciones, siempre puede crear una clase de aserción trivial propia que no se pueda desactivar. El principio de usar aserciones no ha cambiado.

3. Lo único que debe tener en cuenta sobre las aserciones es el contrato de rendimiento de sus interfaces. Tenga en cuenta que esto también podría ser un contrato "implícito" (es decir, cuando una implementación obvia debe ser muy rápida, tomarse un minuto está fuera del contrato de desempeño implícito). Así que asegúrese de verificar sus afirmaciones aceptables en virtud del contrato de rendimiento.

Answer 6

La distinción importante es si cree que un valor incorrecto es el resultado de

a) Un error de programación que debería ser corregido en el código.

b) Un error de entrada que no se puede evitar en el código y en su lugar debe manejarse en tiempo de ejecución.

Para el primer caso, debe usar una aserción, ya que el código del programa deberá ser arreglado. Si es el caso posterior, debe usar una Runtime apropiada o una excepción de verificación.

Las afirmaciones IMHO son para detectar errores de programación y no entradas de usuario / externas. Tal vez el autor esté confundiendo los métodos públicos como una entrada externa cuando tendrá un método público que no sea llamado por una entrada externa.

Usaría aserciones para verificar argumentos para detectar errores de programación. En mi humilde opinión este es a menudo el mejor uso para ellos. El método privado por comparación solo debe llamarse por código en la misma clase y usted debe esperar que sean pruebas de unidad y que tengan acceso / usos limitados posibles.

Creo que es mucho más probable que tenga errores de programación a través de interfaces públicas porque diferentes personas hacen diferentes suposiciones (las aseveraciones son una buena manera de documentar y verificar suposiciones) Las verificaciones internas no son tan útiles como usted esperaría que el mismo programador tenga acceso a El código interno si no se ha escrito toda la base del código interno.

Answer 7

La idea es que no sabes quién usará tu método público. Por lo que debe defenderse contra el uso indebido con cheques normales.

Los métodos privados, por otro lado, deben ser utilizados únicamente por los desarrolladores de su equipo actual, por lo que las verificaciones no son (eso) obligatorias (pero aún así se recomiendan en mi humilde opinión).

Por lo tanto, para verificar la validez de los argumentos en métodos privados, las afirmaciones deberían ser suficientes.

Answer 8

Las aserciones no deben usarse para verificar argumentos en métodos públicos por las siguientes razones:

• las aserciones pueden deshabilitarse y las verificaciones de argumentos nunca deben deshabilitarse, ya que son parte del contrato del método con sus interlocutores
• los fallos de aserción no generan una excepción apropiada para los argumentos no válidos.

Ejemplo:

 /**
* @throws ArithmeticException if divisor is zero
*/
public void int divide(int divisor) {
if (divisor == 0) {
throw new ArithmeticException("Cannot divide by zero");
}
...
}

Si usara una aserción aquí, se podría desactivar y emitiría una AssertionFailedException , que es inútil y poco informativa.

Answer 9

Las aserciones son para la depuración; Los métodos públicos en general no deberían validar las cosas mediante depuraciones, sino verificando los argumentos y lanzando las excepciones apropiadas. Está bien usarlo si desea validar el estado interno del objeto, pero no validar los parámetros.

Answer 10

No hay nada de malo en usar una afirmación en un método público. Se podrían usar para verificar que ciertos invariantes (cosas que crees que son ciertas), sobre el objeto o la clase a la que llamas método, en realidad son ciertas.

Por ejemplo, podría usar una aserción como lo he hecho, en el método public build () de un constructor, para asegurarse de que el constructor se haya inicializado correctamente con mi propio código interno en esa clase (ya que tengo un número de constructores sobrecargados para eso).

Pero lo que NUNCA debes hacer es usar aserciones para verificar los ARGUMENTOS de los métodos públicos. Una distinción importante. Creo que las otras respuestas aquí ya han explicado las razones con suficiente claridad, así que no voy a repetir nada.

Answer 11

Tal como está, la frase que citaste es una tontería, creo.

Para estar seguro, afirmar no es para la validación de parámetros.

Pero en cada programa no trivial hay (o debería haber) un número de invariantes, y este es el lugar donde las aserciones pueden ser útiles. Si puede expresar el invariante en una afirmación, hágalo, no importa si el método es público o no.

Entonces, ocurrirá uno de los siguientes:

a) todo está bien.
b) En el tiempo de ejecución, el programa falla con una aserción no cumplida. Si la afirmación es correcta, se infringe el invariante y tiene la oportunidad de averiguar por qué y corregir el error (o repensar su diseño).