¿Debería un método de recuperación devolver 'nulo' o lanzar una excepción cuando no puede producir el valor de retorno? [cerrado]


503

Tengo un método que se supone que devuelve un objeto si se encuentra.

Si no se encuentra, debería:

  1. volver nulo
  2. lanzar una excepción
  3. otro

57
Hagas lo que hagas, asegúrate de documentarlo. Creo que este punto es más importante que exactamente qué enfoque es el "mejor".
Rik

66
Esto depende de los modismos predominantes del lenguaje de programación. Marque esta pregunta con una etiqueta de lenguaje de programación.
Teddy

3
Devolver nulo solo puede significar éxito o fracaso, que a menudo no es mucha información (algunos métodos pueden fallar de muchas maneras). Las bibliotecas deberían lanzar excepciones para hacer explícitos los errores y de esta manera el programa principal puede decidir cómo manejar el error en un nivel superior (en contraste con la lógica de manejo de errores incorporada).
3k-

1
Me parece que la verdadera pregunta que se hace es si deberíamos considerar excepcional que no se encuentre una entidad, y si es así, ¿por qué? Nadie realmente respondió lo suficiente cómo llegar a esa conclusión, y ahora el Q&A está cerrado. Una verdadera pena que la industria no haya llegado a un consenso sobre este importante tema. Sí, sé que depende . Entonces, explique por qué depende con más que "si es excepcional, tirar"
aplastar el

Respuestas:


484

Si siempre espera encontrar un valor, arroje la excepción si falta. La excepción significaría que hubo un problema.

Si el valor puede faltar o estar presente y ambos son válidos para la lógica de la aplicación, devuelva un valor nulo.

Más importante: ¿Qué haces en otros lugares del código? La consistencia es importante.


30
@Ken: +1, sería bueno mencionar que si arroja una excepción, pero puede detectarla a priori (como HasItem (...)), entonces el usuario debe proporcionar dicho método Has * o Contains.
user7116

44
En lugar de devolver un valor o un valor nulo cuando falta el valor, considere devolver un Quizás <T>. Ver mikehadlow.blogspot.nl/2011/01/monads-in-c-5-maybe.html .
Erwin Rooijakkers

2
En una forma de elección de diseño @ErwinRooijakkers , a partir de Java 8 también podría devolver un <T> Opcional
José Andias

2
Me parece un poco inquietante que cada respuesta haga eco del mismo proverbio: "Si es excepcional, tira". La mayoría de los ingenieros estarán familiarizados con este principio. En mi opinión, la verdadera pregunta aquí es cómo determinar si debe considerarse excepcional. El OP está buscando la mejor práctica con respecto a algo como un patrón de repositorio, por ejemplo. ¿Normalmente se considera excepcional que un objeto no exista dada una clave primaria? Sí, eso es algo que su dominio determinará, pero ¿qué sugieren la mayoría de los expertos con años de experiencia? Ese es el tipo de respuesta que deberíamos ver.
aplastar

44
@crush Creo que un director rector es qué parámetros se pasan a la función . Si pasa una identidad , como si mencionara una clave primaria, debería considerarse excepcional si ese elemento no se encuentra, porque indica un estado inconsistente en el sistema. Ejemplo: GetPersonById(25)arrojaría si esa persona ha sido eliminada, pero GetPeopleByHairColor("red")devolvería un resultado vacío. Entonces, creo que los parámetros dicen algo sobre las expectativas.
John Knoop el

98

Solo lanza una excepción si realmente es un error. Si se espera que el comportamiento del objeto no exista, devuelva el valor nulo.

De lo contrario, es una cuestión de preferencia.


44
No estoy de acuerdo Puede lanzar excepciones como códigos de estado: "NotFoundException"
ACV

Ciertamente no debería ser una cuestión de preferencia. Así es como terminamos con un código inconsistente: si no está entre el código de su equipo, es casi seguro que entrelaza el código de otros desarrolladores con el suyo (bibliotecas externas).
aplastar

44
Creo que manejar el caso nulo es mucho más fácil que "NotFoundException". Piensa en cuántas líneas de try-catch tienes que escribir alrededor de cada solicitud de recuperación que arroja una "NotFoundException" ... Es doloroso preparar todo ese código en mis ojos.
visc

Me gustaría citar a Tony Hoare: "Yo lo llamo mi error de mil millones de dólares". No devolvería nulo, arrojo una excepción y la manejo correctamente, o devuelvo un objeto vacío.
siete

70

Como regla general, si el método siempre debe devolver un objeto, entonces vaya con la excepción. Si anticipa un nulo ocasional y desea manejarlo de una manera determinada, vaya con el nulo.

Hagas lo que hagas, desaconsejo la tercera opción: devolver una cadena que dice "WTF".


Más uno porque en los viejos tiempos lo hice más de un par de veces como una solución "temporal" sucia rápida ... no es una buena idea. Especialmente si va a ser revisado si eres un estudiante.
rciafardone

14
Iba a rechazar el voto ya que las opciones de WTF me parecían increíbles ... pero aparentemente tengo un corazón
swestner

55
lanzar nuevo WtfExcepti😲n
Kamafeather

Creo que sería útil si esta respuesta hablara de las razones por las cuales un método siempre devolvería un objeto versus "un nulo ocasional". ¿Qué garantiza ese tipo de situación? Dé un ejemplo de cuándo podría existir tal circunstancia.
aplastar

51

Si nulo nunca indica un error, simplemente devuelva nulo.

Si nulo es siempre un error, arroje una excepción.

Si nulo es a veces una excepción, codifique dos rutinas. Una rutina arroja una excepción y la otra es una rutina de prueba booleana que devuelve el objeto en un parámetro de salida y la rutina devuelve un falso si no se encontró el objeto.

Es difícil hacer un mal uso de una rutina de prueba. Es muy fácil olvidarse de verificar nulo.

Entonces, cuando nulo es un error, simplemente escribes

object o = FindObject();

Cuando el nulo no es un error, puede codificar algo como

if (TryFindObject(out object o)
  // Do something with o
else
  // o was not found

1
Esta sería una sugerencia más útil si C # proporcionara tuplas reales, por lo que podríamos evitar el uso de un parámetro [out]. Aún así, este es el patrón preferido, entonces +1.
Erik Forbes

2
En mi opinión, el enfoque de prueba es el mejor. No tiene que buscar, entonces, qué sucede si el objeto no puede ser devuelto. Con un método de prueba, inmediatamente sabe qué hacer.
OregonGhost

me recuerda el findy findOrFailde Laravel Eloquent
vivoconunxino

@ErikForbes Sé que su comentario es antiguo, pero ¿no habría sido la respuesta definir un objeto de propiedades múltiples que se devolvería del TryFindObjectmétodo? Las tuplas parecen más un paradigma vago para los programadores que no quieren tomarse el tiempo para definir un objeto que encapsula múltiples valores. Eso es esencialmente todas las tuplas están en el núcleo de todos modos.
aplastar

@crush: los Tuple Literals con nombre son una opción, IMO. Este es un enlace a un patrón asincrónico Try Get con tuplas. stackoverflow.com/questions/1626597/…
ttugates

26

Solo quería recapitular las opciones mencionadas anteriormente, agregando algunas nuevas en:

  1. volver nulo
  2. lanzar una excepción
  3. usar el patrón de objeto nulo
  4. proporcionar un parámetro booleano a su método, para que la persona que llama pueda elegir si quiere que arroje una excepción
  5. proporciona un parámetro adicional, para que la persona que llama pueda establecer un valor que recupere si no se encuentra ningún valor

O puede combinar estas opciones:

Proporcione varias versiones sobrecargadas de su captador, para que la persona que llama pueda decidir qué camino tomar. En la mayoría de los casos, solo el primero tiene una implementación del algoritmo de búsqueda, y los otros simplemente envuelven el primero:

Object findObjectOrNull(String key);
Object findObjectOrThrow(String key) throws SomeException;
Object findObjectOrCreate(String key, SomeClass dataNeededToCreateNewObject);
Object findObjectOrDefault(String key, Object defaultReturnValue);

Incluso si elige proporcionar solo una implementación, es posible que desee utilizar una convención de nomenclatura como esa para aclarar su contrato, y le ayuda si alguna vez decide agregar otras implementaciones también.

No debe usarlo en exceso, pero puede ser útil, especialmente al escribir una clase auxiliar que usará en cientos de aplicaciones diferentes con muchas convenciones de manejo de errores diferentes.


Me gustan los nombres claros de funciones, especialmente orCreate y orDefault.
marcovtwout

55
La mayor parte de esta se puede escribir de forma más limpia con Expected<T> findObject(String)donde Expected<T>tiene las funciones orNull(), orThrow(), orSupplied(Supplier<T> supplier), orDefault(T default). Esto abstrae la obtención de los datos del manejo de errores
WorldSEnder

No sabía sobre <T> esperado hasta ahora. Parece que soy bastante nuevo y podría no haber existido cuando escribí la respuesta original. Tal vez deberías hacer de tu comentario una respuesta adecuada.
Lena Schimmel el

Además, se espera que <T> sea una plantilla de C ++. ¿Existen implementaciones en otros lenguajes orientados a objetos también?
Lena Schimmel el

En Java 8, devolver Opcional <T> (llamado Quizás <T>, etc. en otros idiomas) también es una opción. Esto indica claramente a la persona que llama que no devolver nada es una posibilidad, y no se compilará si la persona que llama no ha manejado esa posibilidad, a diferencia de nulo, que (en Java de todos modos) se compilará incluso si la persona que llama no lo verifica .
Algún tipo

18

Utilice el patrón de objeto nulo o arroje una excepción.


Esta es la verdadera respuesta. Volver nulo es un hábito terrible de los programadores perezosos.
jeremyjjbrown

No puedo creer que esta respuesta aún no haya sido votada a la cima. Esta es la verdadera respuesta, y cualquiera de los dos enfoques es muy fácil y ahorra una gran cantidad de código inflado o NPE.
Bane


3
Si uno usa el patrón de objeto nulo, ¿cómo distinguiría el caso donde la clave está asignada al objeto nulo del caso donde la clave no tiene asignación? Creo que devolver un objeto sin sentido sería mucho peor que devolver nulo. Si devuelve nulo al código que no está preparado para manejarlo, generalmente se generará una excepción. No es la opción óptima de excepción, pero una excepción, no obstante. Es más probable que devolver un objeto sin sentido resulte en un código incorrecto que considera que los datos sin significado son correctos.
supercat

3
¿Cómo se comportaría el objeto nulo para una búsqueda de entidad? Por ejemplo, Person somePerson = personRepository.find("does-not-exist");supongamos que este método devuelve un objeto nulo para ID does-not-exist. ¿Cuál sería entonces el comportamiento correcto somePerson.getAge()? En este momento, todavía no estoy convencido de que el patrón de objeto nulo sea la solución correcta para las búsquedas de entidades.
Abdull

13

Sea coherente con las API que está utilizando.


13

Ventajas de lanzar una excepción:

  1. Flujo de control más limpio en su código de llamada. La comprobación de nulos inyecta una rama condicional que se maneja de forma nativa mediante try / catch. La comprobación de nulo no indica qué es lo que está buscando: ¿está buscando nulo porque está buscando un error que está esperando o está buscando nulo para no pasarlo más adelante en la cadena descendente? ?
  2. Elimina la ambigüedad de lo que significa "nulo". ¿Es nulo representante de un error o es nulo lo que realmente se almacena en el valor? Es difícil de decir cuando solo tienes una cosa en la que basar esa determinación.
  3. Consistencia mejorada entre el comportamiento del método en una aplicación. Las excepciones generalmente se exponen en las firmas de métodos, por lo que puede comprender mejor qué casos extremos representan los métodos en una aplicación y a qué información puede reaccionar su aplicación de manera predecible.

Para obtener más explicaciones con ejemplos, consulte: http://metatations.com/2011/11/17/returning-null-vs-throwing-an-exception/


2
+1 porque el punto 2 es excelente: nulo no tiene el mismo significado que no encontrado. Esto se vuelve más importante cuando se trata de lenguajes dinámicos donde Null podría ser realmente el objeto que la función almacena / recupera, y en ese caso
Adam Terrey el

1
+1 para el punto 2. ¿Es nulo un error? ¿Es nulo lo que se almacena para la clave dada? ¿Es nulo indicativo de que la clave no existe? Esta es la verdadera línea de preguntas que deja en claro que devolver nulo casi nunca es correcto. Esta es probablemente la mejor respuesta aquí, ya que todos los demás acaban de lanzar el ambiguo "Si es excepcional, tirar"
aplastar el

12

depende si tu idioma y código promueven: LBYL (mira antes de saltar) o EAFP (es más fácil pedir perdón que permiso)

LBYL dice que debe verificar los valores (así que devuelva un valor nulo)
EAFP dice que simplemente intente la operación y vea si falla (arroje una excepción)

aunque estoy de acuerdo con lo anterior ... las excepciones deben usarse para condiciones excepcionales / de error, y devolver un valor nulo es mejor cuando se usan cheques.


EAFP vs. LBYL en Python:
http://mail.python.org/pipermail/python-list/2003-May/205182.html ( Archivo Web )


3
En algunos casos, EAFP es el único enfoque significativo. En un mapa / diccionario concurrente, por ejemplo, no hay forma de preguntar si existirá un mapeo cuando se solicite.
Supercat

11

Simplemente pregúntese: "¿es un caso excepcional que no se encuentre el objeto"? Si se espera que suceda en el curso normal de su programa, probablemente no debería generar una excepción (ya que no es un comportamiento excepcional).

Versión corta: use excepciones para manejar un comportamiento excepcional, no para manejar el flujo normal de control en su programa.

-Alan.


5

Las excepciones están relacionadas con el diseño por contrato.

La interfaz de un objeto es en realidad un contrato entre dos objetos, la persona que llama debe cumplir con el contrato o el receptor puede fallar con una excepción. Hay dos posibles contratos.

1) todas las entradas del método son válidas, en cuyo caso debe devolver nulo cuando no se encuentra el objeto.

2) solo alguna entrada es válida, es decir, la que da como resultado un objeto encontrado. En ese caso, DEBE ofrecer un segundo método que permita a la persona que llama determinar si su entrada será correcta. Por ejemplo

is_present(key)
find(key) throws Exception

SI y SOLO SI proporciona ambos métodos del segundo contrato, puede lanzar una excepción, ¡no se encuentra nada!


4

Prefiero simplemente devolver un valor nulo y confiar en que la persona que llama lo maneje adecuadamente. La excepción (por falta de una palabra mejor) es si estoy absolutamente 'seguro' de que este método devolverá un objeto. En ese caso, una falla es un deber excepcional y debe arrojar.


4

Depende de lo que significa que el objeto no se encuentra.

Si se trata de una situación normal, devuelva nulo. Esto es algo que puede suceder de vez en cuando, y las personas que llaman deben verificarlo.

Si se trata de un error, arroje una excepción, las personas que llaman deben decidir qué hacer con la condición de error del objeto faltante.

En última instancia, cualquiera funcionaría, aunque la mayoría de las personas generalmente consideran una buena práctica usar Excepciones solo cuando algo, bueno, Excepcional ha sucedido.


2
¿Cómo elaboraría la declaración del " estado normal de las cosas " y qué criterios utilizará para distinguirla con un error?
user1451111

4

Aquí hay un par de sugerencias más.

Si devuelve una colección, evite devolver nulo, devuelva una colección vacía, lo que hace que la enumeración sea más fácil de tratar sin una verificación nula primero.

Varias API de .NET usan el patrón de un parámetro thrownOnError que le da a la persona que llama la opción de si realmente es una situación excepcional o no si no se encuentra el objeto. Type.GetType es un ejemplo de esto. Otro patrón común con BCL es el patrón TryGet donde se devuelve un valor booleano y el valor se pasa a través de un parámetro de salida.

También puede considerar el patrón Objeto nulo en algunas circunstancias, que puede ser una versión predeterminada o una versión sin comportamiento. La clave es evitar verificaciones nulas en toda la base del código. Consulte aquí para obtener más información http://geekswithblogs.net/dsellers/archive/2006/09/08/90656.aspx


3

En algunas funciones agrego un parámetro:

..., bool verify = true)

Verdadero significa tirar, falso significa devolver algún valor de retorno de error. De esta manera, quien usa esta función tiene ambas opciones. El valor predeterminado debe ser verdadero, para beneficio de aquellos que se olvidan del manejo de errores.


3

Devuelva un valor nulo en lugar de lanzar una excepción y documente claramente la posibilidad de un valor de retorno nulo en la documentación de la API. Si el código de llamada no respeta la API y verifica el caso nulo, lo más probable es que resulte en algún tipo de "excepción de puntero nulo" de todos modos :)

En C ++, puedo pensar en 3 tipos diferentes de configurar un método que encuentre un objeto.

Opcion A

Object *findObject(Key &key);

Devuelve nulo cuando no se puede encontrar un objeto. Agradable y simple Yo iría con este. Los enfoques alternativos a continuación son para personas que no odian a los paramáticos.

Opcion B

void findObject(Key &key, Object &found);

Pase una referencia a la variable que recibirá el objeto. El método arrojó una excepción cuando no se puede encontrar un objeto. Esta convención probablemente sea más adecuada si realmente no se espera que no se encuentre un objeto; por lo tanto, lanza una excepción para indicar que es un caso inesperado.

Opcion C

bool findObject(Key &key, Object &found);

El método devuelve falso cuando no se puede encontrar un objeto. La ventaja de esto sobre la opción A es que puede verificar el caso de error en un paso claro:

if (!findObject(myKey, myObj)) { ...

3

refiriéndome solo al caso donde nulo no se considera un comportamiento excepcional, definitivamente estoy para el método de prueba, está claro, no es necesario "leer el libro" o "mirar antes de saltar" como se dijo aquí

así que básicamente:

bool TryFindObject(RequestParam request, out ResponseParam response)

y esto significa que el código del usuario también será claro

...
if(TryFindObject(request, out response)
{
  handleSuccess(response)
}
else
{
  handleFailure()
}
...

2

Si es importante que el código del cliente sepa la diferencia entre encontrado y no encontrado y se supone que este es un comportamiento de rutina, entonces es mejor devolver nulo. El código del cliente puede decidir qué hacer.


2

En general, debe devolver nulo. El código que llama al método debería decidir si lanzar una excepción o intentar otra cosa.


2

O devolver una opción

Una opción es básicamente una clase de contenedor que obliga al cliente a manejar casos de cabina. Scala tiene este concepto, busque su API.

Luego, tiene métodos como T getOrElse (T valueIfNull) en este objeto que devuelve el objeto encontrado o una alternativa que el cliente especifica.


2

Prefiero volver nulo -

Si la persona que llama lo usa sin verificar, la excepción ocurre allí de todos modos.

Si la persona que llama en realidad no lo uso, no lo gravar una try/ catchbloque


2

Desafortunadamente, JDK es inconsistente, si intentas acceder a una clave no existente en el paquete de recursos, no obtienes una excepción y cuando solicitas valor del mapa, obtienes un valor nulo si no existe. Entonces, cambiaría la respuesta ganadora a lo siguiente, si el valor encontrado puede ser nulo, luego generaría una excepción cuando no se encuentre, de lo contrario, devolvería nulo. Así que siga la regla con una excepción, si necesita saber por qué no se encuentra el valor, siempre genere una excepción, o ...


1

Mientras se suponga que devuelve una referencia al objeto, devolver un NULL debería ser bueno.

Sin embargo, si devuelve todo lo sangriento (como en C ++ si lo hace: 'return blah;' en lugar de 'return & blah;' (o 'blah' es un puntero), entonces no puede devolver un NULL, porque es no del tipo 'objeto'. En ese caso, lanzar una excepción o devolver un objeto en blanco que no tenga un indicador de éxito establecido es cómo abordaría el problema.


1

No piense que nadie mencionó los gastos generales en el manejo de excepciones: se necesitan recursos adicionales para cargar y procesar la excepción, por lo que, a menos que sea un verdadero evento de cierre de la aplicación o de detención del proceso (en adelante, causaría más daño que bien) optaría por devolver un valorar el entorno de llamada podría interpretar como mejor le parezca.


1

Estoy de acuerdo con lo que parece ser el consenso aquí (devolver nulo si "no encontrado" es un resultado normal posible, o lanzar una excepción si la semántica de la situación requiere que siempre se encuentre el objeto).

Sin embargo, existe una tercera posibilidad que podría tener sentido dependiendo de su situación particular. Su método podría devolver un objeto predeterminado de algún tipo en la condición "no encontrado", lo que permite asegurar que el código de llamada siempre recibirá un objeto válido sin la necesidad de una comprobación nula o captura de excepciones.


1

Devuelva un valor nulo, las excepciones son exactamente eso: algo que hace su código que no se espera.



1

Si el método devuelve una colección, devuelva una colección vacía (como se dijo anteriormente). ¡Pero por favor no Collections.EMPTY_LIST o tal! (en el caso de Java)

Si el método recupera un solo objeto, entonces tiene algunas opciones.

  1. Si el método siempre debe encontrar el resultado y es un caso de excepción real no encontrar el objeto, entonces debe lanzar una excepción (en Java: por favor, una excepción no marcada)
  2. (Solo Java) Si puede tolerar que el método arroje una excepción marcada, arroje una excepción ObjectNotFoundException específica del proyecto o similar. En este caso, el compilador te dice si olvidas manejar la excepción. (Este es mi manejo preferido de cosas no encontradas en Java).
  3. Si dice que está realmente bien, si no se encuentra el objeto y su nombre de método es como findBookForAuthorOrReturnNull (..), puede devolver nulo. En este caso lo es recomienda encarecidamente utilizar algún tipo de verificación estática o verificación del compilador, lo que evita la desreferenciación del resultado sin una verificación nula. En el caso de Java puede ser, por ejemplo. FindBugs (vea DefaultAnnotation en http://findbugs.sourceforge.net/manual/annotations.html ) o IntelliJ-Checking.

Tenga cuidado, si decide devolver un valor nulo. Si no es el único programador en el proyecto, obtendrá NullPointerExceptions (en Java o lo que sea en otros idiomas) en tiempo de ejecución. Por lo tanto, no devuelva valores nulos que no se verifican en tiempo de compilación.


No si el código se escribió correctamente para esperar null. Vea la respuesta más votada para más.
Andrew Barber

Pero solo si se asegura en tiempo de compilación, se verifican todos los valores nulos. Esto se puede hacer, utilizando FindBugs @NutNull a nivel de paquete y marque su método como "puede devolver nulo". O para usar un lenguaje como Kotlin o Niza. Pero es mucho más simple no devolver nulo.
iuzuz

"Más simple", tal vez . Pero a menudo simplemente incorrecto
Andrew Barber

1
Nuevamente: lea la respuesta más votada para obtener más información. Básicamente: si es un resultado potencialmente esperado que el libro solicitado no se puede encontrar, una excepción es lo incorrecto que hacer cuando simplemente no se encuentra el libro solicitado, en lugar de que ocurra algún error.
Andrew Barber

1
Estás malentendido mucho aquí. Está aplicando consejos condicionales de manera universal, lo que casi siempre es algo malo. Lea el resto de las respuestas votadas también. Su respuesta solo establece un absoluto y presenta una lógica extremadamente defectuosa.
Andrew Barber

1

Si está utilizando una biblioteca u otra clase que arroja una excepción, debe volver a lanzar a . Aquí hay un ejemplo. Example2.java es como la biblioteca y Example.java usa su objeto. Main.java es un ejemplo para manejar esta excepción. Debe mostrar un mensaje significativo y (si es necesario) el seguimiento de la pila al usuario en el lado de la llamada.

Main.java

public class Main {
public static void main(String[] args) {
    Example example = new Example();

    try {
        Example2 obj = example.doExample();

        if(obj == null){
            System.out.println("Hey object is null!");
        }
    } catch (Exception e) {
        System.out.println("Congratulations, you caught the exception!");
        System.out.println("Here is stack trace:");
        e.printStackTrace();
    }
}
}

Example.java

/**
 * Example.java
 * @author Seval
 * @date 10/22/2014
 */
public class Example {
    /**
     * Returns Example2 object
     * If there is no Example2 object, throws exception
     * 
     * @return obj Example2
     * @throws Exception
     */
    public Example2 doExample() throws Exception {
        try {
            // Get the object
            Example2 obj = new Example2();

            return obj;

        } catch (Exception e) {
            // Log the exception and rethrow
            // Log.logException(e);
            throw e;
        }

    }
}

Example2.java

 /**
 * Example2.java
 * @author Seval
 *
 */
public class Example2 {
    /**
     * Constructor of Example2
     * @throws Exception
     */
    public Example2() throws Exception{
        throw new Exception("Please set the \"obj\"");
    }

}

Si la excepción que se lanzará desde la función no es una excepción de tiempo de ejecución, y se espera que la persona que llama la maneje (en lugar de simplemente terminar el programa), entonces, en lugar de lanzar una excepción desde un subsistema interno que la persona que llama no puede esperar, sería mejor envolver la excepción interna con una excepción externa comprobada, mientras 'encadenando' la excepción interna para que alguien que depure pueda descubrir por qué se lanzó la excepción externa. Por ejemplo, example1 podría usar 'throw new MyCheckedException ("Establezca \" obj \ "", e)' para incluir 'e' en la excepción lanzada.
Algún tipo

0

Eso realmente depende de si espera encontrar el objeto, o no. Si sigue la escuela de pensamiento de que las excepciones deben usarse para indicar algo, bueno, err, excepcional ha ocurrido entonces:

  • Objeto encontrado; devolver objeto
  • Objeto no encontrado; lanzar excepción

De lo contrario, devuelva nulo.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.