Ofrezco una respuesta que no está exactamente en el punto. Por supuesto, puedes usar assert en métodos públicos (o donde quieras).
El punto es más sobre lo que debe hacer o no. Yo mismo entiendo perfectamente la respuesta de otras personas sobre cuándo debería o no debería usar la afirmación.
Pero debo admitir que NUNCA uso aserciones, y que casi nunca veo aserciones en el código. Trabajé solo por unos años, pero en las 4 compañías totalmente diferentes para las que trabajé, no había aserciones en el código. Ya sea la línea de más de 10 millones de aplicaciones web codificadas para reservar vuelos, un centro de control de naves espaciales, un software para administrar hipermercados o un rastreador de errores. Ninguno de ellos utilizó aseveraciones. Todas las empresas tenían diferentes necesidades y métodos. Ninguno usado afirma.
Para mí el motivo es simple. La gente aquí dice que las afirmaciones son para la depuración. Esta bien. Y que puedes desactivarlos para mejorar la velocidad. Eso también ... al principio. Cuanto más complejo sea el programa, más pasarás depuración de tiempo. Y algunos errores, incluso con una cobertura de código del 100%, incluso con extensas pruebas de integración y 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 curioso, 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 esto significa es que nunca se sabe lo que podría ocurrir en la producción.
Y eso si tienes la oportunidad de hacer un control, hazlo. Por supuesto, el comentario de registro es más divertido que útil aquí y sería mejor dejar la excepción emergente.
En todos los casos, no haga una afirmación que se desactivará en la producción. Porque será inútil. Haga que el código normal genere una excepción. Asegúrese de que esté registrado, si corresponde. Asegúrese de que se muestre un error en la IU. Y asegúrese de que pueda obtener la excepción y los registros para investigar.
Lo importante es que un día u otro, algunos usuarios harán cosas que hagan que aparezca 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 buscando por qué diablos el programa tiene este comportamiento extraño, podrás usar la pila completa en un punto de partida y corregir el problema en 2 horas.
Una verificación con una afirmación desactivada es lo mismo que ningún control. Es código que debes escribir, leer y mantener ... Por nada. Entiendo todo el argumento del rendimiento donde las aserciones en la producción disminuyen la velocidad. Sí, en algunos casos, hay un problema de rendimiento. En la mayoría de los casos, no ganarás casi nada y perderás pistas valiosas.
Hay una diferencia entre "no puedo" y "no debería" –
¿Tiene la fuente de esta cita? – jmg
@jmg - He añadido la fuente y la cita precisa en mi respuesta a continuación. Prohíbe las afirmaciones en métodos públicos solo para la comprobación de argumentos. –