Um método de recuperação deve retornar 'null' ou lançar uma exceção quando não puder produzir o valor de retorno? [fechadas]


503

Eu tenho um método que deve retornar um objeto se ele for encontrado.

Se não for encontrado, devo:

  1. retornar nulo
  2. lançar uma exceção
  3. de outros

57
Faça o que fizer, certifique-se de documentá-lo. Eu acho que esse ponto é mais importante do que exatamente qual abordagem é "melhor".
Rik

6
Isso depende dos idiomas predominantes da linguagem de programação. Marque esta pergunta com uma tag de linguagem de programação.
Teddy

3
Retornar nulo pode significar apenas sucesso ou falha, que muitas vezes não é muita informação (alguns métodos podem falhar de várias maneiras). As bibliotecas devem lançar melhor exceções para tornar os erros explícitos e, dessa forma, o programa principal pode decidir como lidar com o erro em um nível superior (em contraste com a lógica de manipulação de erros interna).
3k-

1
Parece-me que a verdadeira pergunta que está sendo feita é se devemos considerar excepcional que uma entidade não seja encontrada e, em caso afirmativo, por quê? Ninguém realmente respondeu suficientemente como chegar a essa conclusão, e agora as perguntas e respostas estão encerradas. Uma pena que a indústria não tenha chegado a um consenso sobre este importante tópico. Sim, eu sei que depende . Então, explique por que isso depende de mais do que "se for excepcional, jogue"
esmague

Respostas:


484

Se você está sempre esperando encontrar um valor, lance a exceção, se estiver faltando. A exceção significaria que havia um problema.

Se o valor estiver ausente ou presente e ambos forem válidos para a lógica do aplicativo, retorne um valor nulo.

Mais importante: o que você faz em outros lugares no código? A consistência é importante.


30
@ Ken: +1, seria bom mencionar que, se você lançar uma exceção, mas puder detectá-la a priori (como HasItem (...)), o usuário deverá fornecer o método Has * ou Contém.
user7116

4
Em vez de retornar um valor ou nulo quando o valor estiver ausente, considere retornar um Talvez <T>. Consulte mikehadlow.blogspot.nl/2011/01/monads-in-c-5-maybe.html .
Erwin Rooijakkers

2
Em um @ErwinRooijakkers maneira escolha de design , a partir de Java 8 você também pode retornar um opcional <T>
José Andias

2
Acho um pouco perturbador todas as respostas ecoam o mesmo provérbio: "Se for excepcional, jogue". A maioria dos engenheiros vai se familiarizar com esse princípio. Na minha opinião, a verdadeira questão aqui é como determinar se deve ser considerado excepcional. O OP está procurando as melhores práticas em relação a algo como um padrão de repositório, por exemplo. Normalmente, é considerado excepcional que um objeto não exista, dada uma chave primária? Sim, isso é algo que o domínio dele determinará, mas o que a maioria dos especialistas com anos de experiência sugere? Esse é o tipo de resposta que devemos ver.
esmagar

4
@crush Acho que o principal guia é quais parâmetros são passados ​​para a função . Se você passar uma identidade , como você mencionou uma chave primária, deve ser considerado excepcional se esse item não for encontrado, porque indica um estado inconsistente no sistema. Exemplo: GetPersonById(25)jogaria se essa pessoa fosse excluída, mas GetPeopleByHairColor("red")retornaria um resultado vazio. Então, acho que os parâmetros dizem algo sobre as expectativas.
John Knoop

98

Lance uma exceção apenas se for realmente um erro. Se o comportamento esperado para o objeto não existir, retorne o valor nulo.

Caso contrário, é uma questão de preferência.


4
Eu não concordo Você pode lançar exceções como códigos de status: "NotFoundException"
ACV

Certamente não deveria ser uma questão de preferência. É assim que terminamos com um código inconsistente - se não estiver entre o código da sua equipe, então quase certamente quando você entrelaça o código de outros desenvolvedores com o seu (bibliotecas externas).
esmagar

4
Eu acho que lidar com o caso nulo é muito mais fácil do que "NotFoundException". Pense em quantas linhas de try-catch você precisa escrever em cada solicitação de recuperação que gera uma "NotFoundException" ... É doloroso preparar todo esse código em meus olhos.
visc

eu gostaria de citar Tony Hoare: "Eu chamo de erro do meu bilhão de dólares". Eu não retornaria nulo, ou lançaria uma exceção e a manipularia corretamente ou retornaria um objeto vazio.
sete

70

Como regra geral, se o método sempre retornar um objeto, vá com a exceção. Se você antecipar o nulo ocasional e quiser lidar com isso de uma certa maneira, vá com o nulo.

Faça o que fizer, desaconselho a terceira opção: retornar uma sequência que diz "WTF".


Mais uma, porque nos bons velhos tempos eu fazia isso mais de duas vezes como uma correção "temporal" suja e rápida ... não é uma boa ideia. Especialmente se for revisado se você for um estudante.
Rciafardone 13/03/2014

14
Eu estava indo para baixo voto desde as opções WTF parecia incrível para mim ... mas, aparentemente, eu tenho um coração
swestner

5
jogar novo WtfExcepti😲n
Kamafeather

Eu acho que seria útil se essa resposta falasse sobre as razões pelas quais um método sempre retornaria um objeto versus "um nulo ocasional". O que justifica esse tipo de situação? Dê um exemplo de quando essa circunstância pode existir.
esmagar

51

Se nulo nunca indicar um erro, basta retornar nulo.

Se nulo é sempre um erro, lance uma exceção.

Se null for algumas vezes uma exceção, codifique duas rotinas. Uma rotina lança uma exceção e a outra é uma rotina de teste booleana que retorna o objeto em um parâmetro de saída e a rotina retorna false se o objeto não foi encontrado.

É difícil usar mal a rotina Try. É muito fácil esquecer de verificar se há nulo.

Então, quando nulo é um erro, basta escrever

object o = FindObject();

Quando o nulo não é um erro, você pode codificar algo como

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

1
Essa seria uma sugestão mais útil se o C # fornecesse tuplas reais, para evitar o uso de um parâmetro [out]. Ainda assim, este é o padrão preferido, então +1.
Erik Forbes

2
Na minha opinião, a abordagem try é a melhor. Você não precisa procurar o que acontece se o objeto não puder ser retornado. Com um método Try, você imediatamente sabe o que fazer.
OregonGhost 6/10/08

lembra-me o finde findOrFailde Laravel Eloquent
vivoconunxino

@ErikForbes Eu sei que seu comentário é antigo, mas a resposta não seria definir um objeto de propriedade múltipla que seria retornado do TryFindObjectmétodo? As tuplas parecem um paradigma preguiçoso para programadores que não desejam reservar um tempo para definir um objeto que encapsule vários valores. Isso é essencialmente todas as tuplas estão no centro de qualquer maneira.
esmagar

@crush - Literais de tupla nomeados são uma opção, IMO. Este é um link para um padrão Try Get assíncrono com tuplas. stackoverflow.com/questions/1626597/…
ttugates

26

Eu só queria recapitular as opções mencionadas anteriormente, lançando algumas novas em:

  1. retornar nulo
  2. lançar uma exceção
  3. use o padrão de objeto nulo
  4. forneça um parâmetro booleano ao seu método, para que o chamador possa escolher se deseja que você lance uma exceção
  5. forneça um parâmetro extra, para que o chamador possa definir um valor que ele recupera se nenhum valor for encontrado

Ou você pode combinar estas opções:

Forneça várias versões sobrecarregadas do seu getter, para que o chamador possa decidir qual caminho seguir. Na maioria dos casos, apenas o primeiro tem uma implementação do algoritmo de pesquisa e os outros apenas envolvem o primeiro:

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

Mesmo se você optar por fornecer apenas uma implementação, convém usar uma convenção de nomenclatura como essa para esclarecer seu contrato, e isso ajudará você a decidir adicionar outras implementações também.

Você não deve usá-lo em excesso, mas pode ser útil, especialmente ao escrever uma classe auxiliar que você usará em centenas de aplicativos diferentes, com muitas convenções diferentes de tratamento de erros.


Gosto dos nomes claros das funções, especialmente orCreate e orDefault.
marcovtwout

5
A maior parte deste pode ser mais limpa escrito com Expected<T> findObject(String)onde Expected<T>tem as funções orNull(), orThrow(), orSupplied(Supplier<T> supplier), orDefault(T default). Isso abstrai a obtenção dos dados do tratamento de erros.
WorldSEnder

Eu não sabia sobre o esperado <T> até agora. Parece ser bastante novo e talvez não existisse quando escrevi a resposta original. Talvez você deva fazer do seu comentário uma resposta adequada.
Lena Schimmel

Além disso, o esperado <T> é um modelo C ++. Também existem implementações em outras linguagens orientadas a objetos?
Lena Schimmel

No Java 8, o retorno de opcional <T> (chamado talvez <T> etc. em outros idiomas) também é uma opção. Isso indica claramente ao chamador que não retornar nada é uma possibilidade e não será compilado se o chamador não tiver tratado essa possibilidade, em vez de nulo, que (em Java de qualquer maneira) será compilado mesmo que o chamador não a verifique .
Some Guy

18

Use o padrão de objeto nulo ou lance uma exceção.


Esta é a verdadeira resposta. Retornar null é um péssimo hábito de programadores preguiçosos.
Jeremyjjbrown # 23/13

Não acredito que essa resposta ainda não tenha sido votada para o topo. Essa é a resposta real, e qualquer uma dessas abordagens é fácil e economiza muito NPEs.
Bane


3
Se alguém usar o padrão de objeto nulo, como distinguir o caso em que a chave é mapeada para o objeto nulo do caso em que a chave não possui mapeamento? Eu acho que retornar um objeto sem sentido seria muito pior do que retornar nulo. Retornar null ao código que não está preparado para lidar com isso geralmente resultará em uma exceção. Não é a escolha ideal de exceção, mas uma exceção, no entanto. O retorno de um objeto sem sentido provavelmente resultará no código incorretamente, considerando os dados sem sentido como corretos.
Supercat #

3
Como o objeto nulo se comportaria para uma pesquisa de entidade? Por exemplo, Person somePerson = personRepository.find("does-not-exist");vamos supor que esse método retorne um objeto nulo para o ID does-not-exist. Qual seria então o comportamento correto somePerson.getAge()? No momento, ainda não estou convencido de que o padrão de objeto nulo seja a solução certa para pesquisas de entidade.
Abdull

13

Seja consistente com as APIs que você está usando.


13

Vantagens de lançar uma exceção:

  1. Fluxo de controle mais limpo no seu código de chamada. A verificação de nulo injeta um ramo condicional que é tratado nativamente por try / catch. Verificar nulo não indica o que você está verificando - você está verificando nulo porque está procurando um erro que está esperando ou está verificando se está nulo para não passar adiante no downchain ?
  2. Remove a ambiguidade do que "nulo" significa. É nulo representativo de um erro ou é nulo o que realmente é armazenado no valor? Difícil dizer quando você tem apenas uma coisa para basear essa determinação.
  3. Consistência aprimorada entre o comportamento do método em um aplicativo. As exceções são normalmente expostas nas assinaturas de método, para que você possa entender melhor para que casos os métodos de um aplicativo são responsáveis ​​e quais informações ele pode reagir de maneira previsível.

Para obter mais explicações com exemplos, consulte: http://metatations.com/2011/11/17/returning-null-vs-throwing-an-exception/


2
+1 porque o ponto 2 é excelente - nulo não tem o mesmo significado que não foi encontrado. Isto tornará mais importante quando se lida com linguagens dinâmicas, onde Null poderia realmente ser o objeto que está sendo armazenado / recuperadas pela função - e nesse caso
Adam Terrey

1
+1 para o ponto 2. Nulo é um erro? É nulo o que é armazenado para a chave especificada? Nulo é indicativo de que a chave não existe? Essas são as linhas reais de perguntas que deixam claro que retornar nulo quase nunca está correto. Esta é provavelmente a melhor resposta aqui, já que todo mundo acabou de lançar o ambíguo "Se for excepcional, jogue"
esmague

12

depende se seu idioma e código promoverem: LBYL (olhe antes de pular) ou EAFP (mais fácil pedir perdão do que permissão)

O LBYL diz que você deve verificar os valores (portanto, retorne um nulo) O
EAFP diz apenas para tentar a operação e ver se ela falha (lança uma exceção)

embora eu concorde com o acima. exceções devem ser usadas para condições excepcionais / de erro, e retornar um nulo é melhor ao usar verificações.


EAFP vs. LBYL em Python:
http://mail.python.org/pipermail/python-list/2003-May/205182.html ( arquivo da web )


3
Em alguns casos, o EAFP é a única abordagem significativa. Em um mapa / dicionário simultâneo, por exemplo, não há como perguntar se um mapeamento existirá quando solicitado.
supercat

11

Apenas pergunte a si mesmo: "é um caso excepcional que o objeto não foi encontrado"? Se é esperado que isso aconteça no curso normal do seu programa, você provavelmente não deve gerar uma exceção (já que não é um comportamento excepcional).

Versão curta: use exceções para lidar com um comportamento excepcional, não para lidar com o fluxo normal de controle em seu programa.

Alan.


5

As exceções estão relacionadas ao Design por contrato.

A interface de um objeto é na verdade um contrato entre dois objetos, o chamador deve cumprir o contrato ou o receptor pode apenas falhar com uma exceção. Existem dois contratos possíveis

1) todas as entradas que o método é válido; nesse caso, você deve retornar nulo quando o objeto não for encontrado.

2) apenas alguma entrada é válida, ou seja, a que resulta em um objeto encontrado. Nesse caso, você DEVE oferecer um segundo método que permita ao chamador determinar se sua entrada estará correta. Por exemplo

is_present(key)
find(key) throws Exception

SE e SOMENTE SE você fornecer os dois métodos do 2º contrato, você poderá lançar uma exceção se nada for encontrado!


4

Prefiro apenas retornar um nulo e confiar no chamador para lidar com isso adequadamente. A exceção (por falta de uma palavra melhor) é se estou absolutamente "certo" de que esse método retornará um objeto. Nesse caso, uma falha é excepcional e deve ser lançada.


4

Depende do que significa que o objeto não foi encontrado.

Se for um estado normal, retorne nulo. Isso é apenas algo que pode acontecer de vez em quando, e os chamadores devem verificar isso.

Se for um erro, em seguida, lançar uma exceção, os chamadores devem decidir o que fazer com a condição de erro do objeto ausente.

Em última análise, ambos funcionariam, embora a maioria das pessoas considere geralmente uma boa prática usar apenas exceções quando algo, bem, excepcional aconteceu.


2
Como você elaboraria a declaração do " estado normal das coisas " e quais critérios você usará para distingui-la com um erro.
user1451111

4

Aqui estão mais algumas sugestões.

Se retornar uma coleção, evite retornar nulo, retorne uma coleção vazia que facilite o processamento da enumeração sem uma verificação nula.

Várias APIs .NET usam o padrão de um parâmetro thrownOnError que permite ao chamador escolher se é realmente uma situação excepcional ou não, se o objeto não for encontrado. Type.GetType é um exemplo disso. Outro padrão comum com BCL é o padrão TryGet, em que um booleano é retornado e o valor é passado através de um parâmetro de saída.

Você também pode considerar o padrão Null Object em algumas circunstâncias, que podem ser um padrão ou uma versão sem comportamento. A chave é evitar verificações nulas em toda a base de código. Veja aqui para mais informações http://geekswithblogs.net/dsellers/archive/2006/09/08/90656.aspx


3

Em algumas funções, adiciono um parâmetro:

..., bool verify = true)

Verdadeiro significa jogar, falso significa retornar algum valor de retorno de erro. Dessa forma, quem usa essa função possui as duas opções. O padrão deve ser verdadeiro, para o benefício daqueles que esquecem o tratamento de erros.


3

Retorne um nulo em vez de lançar uma exceção e documente claramente a possibilidade de um valor de retorno nulo na documentação da API. Se o código de chamada não respeitar a API e verificar o caso nulo, provavelmente resultará em algum tipo de "exceção de ponteiro nulo" de qualquer maneira :)

Em C ++, posso pensar em três tipos diferentes de configuração de um método que encontra um objeto.

Opção A

Object *findObject(Key &key);

Retorne nulo quando um objeto não puder ser encontrado. Agradável e simples. Eu iria com este. As abordagens alternativas abaixo são para pessoas que não odeiam parâmetros exagerados.

Opção B

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

Passe uma referência à variável que estará recebendo o objeto. O método gerou uma exceção quando um objeto não pode ser encontrado. Essa convenção provavelmente é mais adequada se não for realmente esperado que um objeto não seja encontrado - portanto, você lança uma exceção para indicar que é um caso inesperado.

Opção C

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

O método retorna false quando um objeto não pode ser encontrado. A vantagem dessa opção A é que você pode verificar o caso de erro em uma etapa clara:

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

3

referindo-me apenas ao caso em que nulo não é considerado um comportamento excepcional, eu definitivamente sou o método try, é claro, não há necessidade de "ler o livro" ou "olhar antes de pular", como foi dito aqui

então, basicamente:

bool TryFindObject(RequestParam request, out ResponseParam response)

e isso significa que o código do usuário também ficará claro

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

2

Se é importante que o código do cliente saiba a diferença entre encontrado e não encontrado e esse seja um comportamento de rotina, é melhor retornar nulo. O código do cliente pode decidir o que fazer.


2

Geralmente, ele deve retornar nulo. O código que chama o método deve decidir se deve lançar uma exceção ou tentar outra coisa.


2

Ou retorne uma opção

Uma opção é basicamente uma classe de contêiner que força o cliente a lidar com casos de booth. Scala tem esse conceito, procure sua API.

Então você tem métodos como T getOrElse (T valueIfNull) nesse objeto para retornar o objeto encontrado ou uma alternativa às especificações do cliente.


2

Prefere retornar null -

Se o chamador o usa sem verificar, a exceção acontece exatamente assim.

Se o chamador não o usar, não taxe um bloco try/catch


2

Infelizmente, o JDK é inconsistente. Se você tentar acessar uma chave inexistente no pacote de recursos, não encontrará uma exceção e, ao solicitar o valor do mapa, será nulo se ele não existir. Então, eu mudaria a resposta do vencedor da seguinte forma: se o valor encontrado puder ser nulo, geraria uma exceção quando não for encontrado; caso contrário, retorne nulo. Portanto, siga a regra com uma exceção, se você precisar saber por que o valor não é encontrado, sempre aumente a exceção ou ..


1

Desde que deva retornar uma referência ao objeto, retornar um NULL deve ser bom.

No entanto, se estiver retornando a coisa toda sangrenta (como em C ++, se você fizer: 'return blá;' em vez de 'return blá;' (ou 'blá' é um ponteiro), não será possível retornar um NULL, porque é não do tipo 'objeto'. Nesse caso, lançar uma exceção ou retornar um objeto em branco que não possui um sinalizador de sucesso definido é como eu abordaria o problema.


1

Não pense que alguém mencionou a sobrecarga no tratamento de exceções - gasta recursos adicionais para carregar e processar a exceção, a menos que seja um verdadeiro evento de interrupção ou interrupção do processo de aplicativos (daqui para frente causaria mais danos do que benefícios). valor que o ambiente de chamada poderia interpretar como entender.


1

Concordo com o que parece ser o consenso aqui (retornar nulo se "não encontrado" for um resultado possível normal ou lançar uma exceção se a semântica da situação exigir que o objeto seja sempre encontrado).

Há, no entanto, uma terceira possibilidade que pode fazer sentido, dependendo da sua situação particular. Seu método pode retornar um objeto padrão de algum tipo na condição "não encontrado", permitindo que o código de chamada tenha certeza de que sempre receberá um objeto válido sem a necessidade de verificação nula ou captura de exceção.


1

Retorne um nulo, as exceções são exatamente isso: algo que seu código faz que não é esperado.



1

Se o método retornar uma coleção, retorne uma coleção vazia (como dito acima). Mas não use Collections.EMPTY_LIST ou algo semelhante! (no caso de Java)

Se o método recuperar um único objeto, você terá algumas opções.

  1. Se o método sempre encontrar o resultado e for um caso de exceção real para não encontrar o objeto, você deverá lançar uma exceção (em Java: por favor, uma exceção desmarcada)
  2. (Somente Java) Se você puder tolerar que o método gere uma exceção verificada, gere um ObjectNotFoundException específico do projeto ou semelhante. Nesse caso, o compilador diz se você esquecer de lidar com a exceção. (Este é o meu tratamento preferido de coisas não encontradas em Java.)
  3. Se você diz que está realmente ok, se o objeto não for encontrado e o nome do seu método for como findBookForAuthorOrReturnNull (..), você poderá retornar nulo. Nesse caso, é altamente recomendável usar algum tipo de verificação estática ou verificação do compilador, o que impede a desreferenciação do resultado sem uma verificação nula. No caso de Java, pode ser por exemplo. FindBugs (consulte DefaultAnnotation em http://findbugs.sourceforge.net/manual/annotations.html ) ou IntelliJ-Checking.

Cuidado, se você decidir retornar um nulo. Se você não é o único programador do projeto, receberá NullPointerExceptions (em Java ou qualquer outra linguagem) em tempo de execução! Portanto, não retorne nulos que não são verificados no momento da compilação.


Não se o código foi escrito corretamente para esperar null. Veja a resposta mais votada para obter mais.
Andrew Barber

Mas somente se você garantir, em tempo de compilação, que todos os nulos serão verificados. Isso pode ser feito, usando FindBugs @NutNull no nível do pacote e marque seu método como "pode ​​retornar nulo". Ou para usar um idioma como o Kotlin ou o Nice. Mas é muito mais simples não retornar nulo.
Iuzuz

"Mais simples", talvez . Mas muitas vezes incorreto
Andrew Barber

1
Novamente: Leia a resposta mais votada para obter mais informações. Basicamente: se for um resultado potencialmente esperado que o livro solicitado não possa ser encontrado, uma exceção é a coisa errada a ser feita quando o livro solicitado simplesmente não for encontrado, em oposição a algum erro.
Andrew Barber

1
Você está entendendo muito mal aqui. Você está aplicando conselhos condicionais universalmente, o que quase sempre é uma coisa ruim a se fazer. Leia o restante das respostas votadas também. Sua resposta apenas afirma um absoluto e apresenta uma lógica extremamente defeituosa para ele.
Andrew Barber

1

Se você estiver usando uma biblioteca ou outra classe que lança uma exceção, você deve repeti- la novamente . Aqui está um exemplo. Example2.java é como biblioteca e Example.java usa seu objeto. Main.java é um exemplo para lidar com essa exceção. Você deve mostrar uma mensagem significativa e (se necessário) empilhar o rastreamento para o usuário no lado de chamada.

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\"");
    }

}

Se a exceção a ser lançada a partir da função não for uma exceção em tempo de execução, e o chamador deve tratá-la (em vez de apenas encerrar o programa), em vez de lançar uma exceção de um subsistema interno que o chamador não pode esperar, seria melhor agrupar a exceção interna com uma exceção externa verificada, enquanto 'encadeava' a exceção interna para que alguém depure para descobrir por que a exceção externa foi lançada. Por exemplo, o exemplo1 pode usar 'throw new MyCheckedException ("Defina \ \ obj \" ", e)' para incluir 'e' na exceção lançada.
Some Guy

0

Isso realmente depende se você espera encontrar o objeto ou não. Se você seguir a escola de pensamento de que exceções devem ser usadas para indicar algo, bem, erre, excepcional ocorreu:

  • Objeto encontrado; retornar objeto
  • Objeto não encontrado; lançar exceção

Caso contrário, retorne nulo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.