Tengo la tentación de agregar un sufijo como "Ex" para diferenciar los métodos (con firmas similares) que arrojan Excepciones de aquellos que no lo hacen.¿Hay una convención de nomenclatura particular para los métodos de Java que generan excepciones?
¿Existe tal convención?
Sí, los nombre de la misma manera que los métodos que no.
¿No es la especificación de excepción suficiente?
Editar: Si tiene métodos similares que arrojan/no tiran, recomiendo el patrón Parse/TryParse (Parse siendo reemplazado por la operación). .NET Framework lo usa con frecuencia (Dictionary<T,K>.TryGetValue, Monitor.TryEnter, int.TryParse, etc., etc.).
¿Por qué haría tal cosa en Java? Ya tiene especificadores de excepciones integrados en el lenguaje. El compilador le impedirá llamar a un método que explícitamente arroja una excepción sin que se tome alguna medida de su parte para manejar o permitir que la excepción se propague.
No hagas eso.
Esto es como preguntar "¿existe una convención de nombres para los métodos que toman dos cadenas como parámetros".
Java ha comprobado las excepciones, lo que significa que debe declararlas de todos modos. Para que pueda ver fácilmente si se lanzará una excepción y qué tipo de excepción. Ni siquiera puede compilar el código que llama al método sin agregar código de manejo de excepciones.
Actualización: Parece que su intención es tener métodos que comprueben si una determinada condición es verdadera, pero no desea devolver simplemente falso, pero arroje una excepción si la condición no se cumple, para que pueda también transmitir un mensaje de explicación (en la excepción). Creo que el prefijo "valer" o "garantizar" tiene sentido:
// instead of
if (! isAuthenticated())
throw new NotAuthenticatedException("not sure why at this point...");
// you do
assertAuthentication();
// which will throw NotAuthenticatedException("proper explanation") inside
Las excepciones son parte de la firma del método en Java, por lo tanto, dicha convención de nomenclatura sería redundante.
Notación húngara para los métodos que arrojan excepciones? Quel horror!
¿Se refiere a excepciones marcadas o no marcadas? ¿Por qué demonios querrías hacer eso?
Cuando lo piense bien, debería agregar su convención a cada método, porque siempre existe la posibilidad de un error, un NPE o cualquier otra cosa que podría salir mal.
La cláusula "throws" es suficiente cuando ha marcado excepciones, y no hay un buen propósito en la tierra verde de Dios para las excepciones sin marcar.
No lo hagas. Por favor.
No hay convención y agregar un ex hará que el nombre sea más difícil de leer y feo en busca del programador java promedio.
Pero a veces me podría imaginar que haría que tu código sea más rápido y comprensible para agregar una prueba a los métodos que probablemente arrojen una excepción. Especialmente si no están marcadas.
No tiene que ser algo tan feo como se puede encontrar en muchos programas c/C++ donde se usa _name o mName para miembros o iValue para enteros. Pero en Java también hay algunas convenciones. Si un método devuelve un entero con el prefijo es ... set, get y test son los ejemplos más utilizados para esto. Todo esto está documentado en el encabezado del método, a través de anotaciones de tipo de retorno, etc. ... Pero agregar una palabra al nombre de la función hace que sea más fácil y rápido de leer y entender.
¿Por qué no? Trate de dar a los programadores que leen su código una sugerencia subconsciente de que es probable que este método arroje una excepción. Al igual que tryCopyFile en lugar de tryWriteFile.
Creo que el prefijo "probar" no es tan bueno. Para mí, eso parece insinuar que no se lanzará una excepción. Como Lock.tryLock(), que intentará obtener un bloqueo, pero devuelve falso si eso no fue posible. – Thilo
No hay ninguno que yo sepa.
En mi opinión, el único momento en que algo así tiene sentido es en los casos de prueba unitaria (por ejemplo, testFooExpectingException()). Pero eso no es realmente de lo que estás hablando.
No existe tal convención porque cada método puede arrojar excepciones, independientemente de si las declara o no. También es algo redundante en este día y edad de información sobre herramientas IDE (a menos que no esté usando un IDE, por supuesto).
Tengo curiosidad por saber por qué está tentado a usar una convención de nomenclatura así.
De vez en cuando se encontrará con un caso en el que podría tener sentido un nombre de método como getSafely() (devuelve un valor predeterminado en el caso de que el valor real no sea válido, para el código que no le importa demasiado sobre los valores reales frente a los marcadores de posición) o su inverso getOrBlowUp() (para el código de fallas donde un valor faltante es técnicamente posible pero indica un error en el código que se supone que establece el valor).
Pero el punto aquí no es "el método 2 se produce una excepción, el método 1 no" - porque, como se mencionó anteriormente, cualquier código podrían lanzar una RuntimeException. El punto es que los dos métodos tienen una semántica diferente para el manejo de errores, específica para diferentes casos de uso, y que es lo que los nombres de los métodos intentan capturar.
Incluso entonces, el código generalmente sería más limpio si pudiera salirse con un comportamiento u otro, y llame al método get().
Un paralelo útil aquí podría ser the distinction between Systems Hungarian and Apps Hungarian en notación húngara. (Véase también this piece on coding conventions de Joel on Software.)
countiCount. Esta es la forma más común de notación húngara y en mi humilde opinión es (1) bastante inútil con un IDE moderno y (2) potencialmente engañoso, si alguien cambia la declaración de tipo sin cambiar el nombre de la variable.index que representa una fila de datos se convierte en drIndex y index que representa una columna de anotación se convierte en acIndex. Esto es mucho más útil y mucho menos probable que cause problemas.Llamar a su método getEx() es Systems Hungarian.
Si necesita estos métodos diferenciados, estoy seguro de que puede hacerlo en el nombrar sin necesidad de utilizar un sufijo o nada, que es (como otros han señalado) bastante espantosa.
Por qué tienen:
boolean authenticate(String username, String password);
y (digamos)
void authenticateEx(String username, String password) throws WhateverException;
cuando en realidad se podría hacer que una parte significativa del nombre mediante la transmisión de la intención real:
void ensureCanAuthenticate(String username, String password);
// or
void assertValidCredentials(...);
// or
void authenticateOrDie(...);
... o cualquier cantidad de otros nombres (probablemente mejores) que en realidad transmiten la intención en lugar de confiar en un sufijo confuso ix.
+1 para assertValidCredentials – Thilo
Spring LDAP tiene 4 métodos de "autentificación" que no arrojan excepciones. Me gustaría agregar un nuevo método de "autentificación" que * arroje^excepciones y sería preferible nombrar estos nuevos métodos algo que los diferenciaría de los que no lo hacen. – lyates
Existe una convención de nombres para los métodos opuestos, de mejor esfuerzo, que ignoran las excepciones y continúan: los métodos llamados safeClose no arrojan NullPointerExceptions, o IOException, o SQLException incluso cuando la operación de cierre falló. – Thilo
Necesito atrapar la AuthenticationException de los métodos de "autenticación" para poder explicar el motivo de la falla al usuario. – lyates