Os tipos de exceções reutilizados devem ser preferidos aos de uso único?

Digamos que eu tenho Doors que são gerenciados por a DoorService. Ele DoorServiceé responsável por abrir, fechar e trancar as portas armazenadas no banco de dados.

public interface DoorService
{
    void open(Door door) throws DoorLockedException, DoorAlreadyOpenedException;

    void close(Door door) throws DoorAlreadyClosedException;

    /**
     * Closes the door if open
     */
    void lock(Door door) throws DoorAlreadyLockedException;
}

Para o método lock, existe um DoorAlreadyLockedExceptione, para o método aberto, existe um DoorLockedException. Esta é uma opção, mas existem outras opções possíveis:

1) Use DoorLockedExceptionpara tudo, é um pouco estranho ao capturar a exceção em uma lock()chamada

try
{
    doorService.lock(myDoor);
}
catch(DoorLockedException ex) // door ALREADY locked
{
    //error handling...
}

2) Tenha os 2 tipos de exceções DoorLockedExceptioneDoorAlreadyLockedException

3) Tenha os 2 tipos de exceções, mas deixe DoorAlreadyLockedException extends DoorLockedException

Qual é a melhor solução e por quê?

Sei que as pessoas fazem muito uso de exceções para controle de fluxo, mas esse não é o maior problema aqui. Eu vejo uma enorme violação de separação de consulta de comando . Mas mesmo isso não é o pior.

Não, o pior está aqui:

/**
 * Closes the door if open
 */

Por que diabos todo o resto explode se sua suposição sobre o estado das portas está errada, mas lock()apenas corrige isso para você? Esqueça que isso torna impossível trancar a porta, o que é absolutamente possível e ocasionalmente útil. O problema aqui é que você misturou duas filosofias diferentes para lidar com suposições incorretas. Isso é confuso. Não faça isso. Não no mesmo nível de abstração com o mesmo estilo de nomenclatura. Ow! Leve uma dessas idéias para fora. Os métodos de serviço na porta devem funcionar da mesma maneira.

Quanto à violação da Separação de Consulta de Comando, não devo tentar fechar uma porta para descobrir se está fechada ou aberta. Eu deveria ser capaz de perguntar. O serviço de porta não fornece uma maneira de fazer isso sem alterar possivelmente o estado da porta. Isso piora muito os comandos que também retornam valores (um mal-entendido comum sobre o que é o CQS). Aqui, comandos de alteração de estado são a única maneira de fazer consultas! Ow!

Quanto às exceções serem mais caras que os códigos de status, isso é conversa sobre otimização. Rápido o suficiente é rápido o suficiente. Não, o verdadeiro problema é que os humanos não esperam exceções para casos típicos. Você pode discutir sobre o que é típico, tudo que você gosta. Para mim, a grande questão é quão legível você está criando o código de uso.

ensureClosed(DoorService service, Door door){
  // Need door closed and unlocked. No idea of its state. What to do?
  try {
    service.open(door)
    service.close(door)
  } 
  catch( DoorLockedException e ){
    //Have no way to unlock the door so give up and die
    log(e);
    throw new NoOneGaveMeAKeyException(e);      
  }
  catch( DoorAlreadyOpenedException e ){
    try { 
      service.close(door);
    }
    catch( DoorAlreadyClosedException e ){
      //Some multithreaded goof has been messing with our door.
      //Oh well, this is what we wanted anyway.
      //Hope they didn't lock it.
    }
  }
}

Por favor, não me faça escrever um código como este. Por favor, nos dê isLocked()e isClosed()métodos. Com quem eu posso escrever meus próprios ensureClosed()e ensureUnlocked()métodos fáceis de ler. Aqueles que só são lançados se suas condições de postagem forem violadas. Prefiro apenas descobrir que você já escreveu e testou, é claro. Apenas não os misture com os que jogam quando não podem mudar de estado. No mínimo, dê a eles nomes distintos.

_{Faça o que fizer, por favor, não ligue para nada tryClose(). Esse é um nome terrível.}

Quanto DoorLockedExceptionsozinho vs também ter DoorAlreadyLockedExceptionmal dizer isso: é tudo sobre o uso de código. Por favor, não projete serviços como esse sem escrever o código de uso e ver a bagunça que você está criando. Refatorar e redesenhar até que o código de uso seja pelo menos legível. De fato, considere escrever o código usando primeiro.

ensureClosed(DoorService service, Door door){
  if( !service.isClosed(door) ){
    try{
      service.close(door);
    }
    catch( DoorAlreadyClosedException e ){
      //Some multithreaded goof has been messing with our door.
      //Oh well, this is what we wanted anyway.
      //Hope they didn't lock it.
    }
  } else {
    //This is what you wanted, so quietly do nothing. 
    //Why are you even here? Who bothers to write empty else conditions?
  }
}

ensureUnlocked(DoorService service, Door door){
  if( service.islocked(door) ){
    throw new NoOneGaveMeAKeyException(); 
  }
}

Fazer uma distinção DoorLockedExceptione DoorAlreadyLockedExceptionsugerir que diferentes tipos de exceção estão sendo usados ​​para controle de fluxo, uma prática que já é amplamente considerada um antipadrão.

Ter vários tipos de exceção para algo tão benigno é gratuito. A complexidade adicional não é compensada pelos benefícios adicionais.

Basta usar DoorLockedExceptionpara tudo.

Melhor ainda, simplesmente não faça nada. Se a porta já estiver trancada, ela ainda estará no estado correto quando o lock()método for concluído. Não crie exceções para condições que não sejam dignas de nota.

Se você ainda não se sentir confortável com isso, renomeie seu método ensureDoorLocked().

O assunto desta pergunta "Os tipos de exceções recicladas devem ser favorecidos em relação aos de uso único?" parece ter sido ignorado, não apenas nas respostas, mas nos detalhes das perguntas (as respostas foram nos detalhes da pergunta).

Concordo com a maioria das críticas ao código que os entrevistados ofereceram.

Mas, como resposta à pergunta principal, eu diria que você deve preferir reutilizar 'exceções recicladas' em vez de 'uso único'.

No uso mais típico do tratamento de exceções, você tem uma grande DISTÂNCIA no código entre o local onde a exceção é detectada e lançada e onde a exceção é capturada e manipulada. Isso significa que o uso de tipos privados (modulares) no tratamento de exceções geralmente não funcionará bem. Um programa típico com manipulação de exceções - terá vários locais de nível superior no código em que as exceções são tratadas. E como esses são locais de nível superior, é difícil para eles terem conhecimento detalhado sobre aspectos estreitos de módulos específicos.

Em vez disso, eles provavelmente terão manipuladores de alto nível para alguns problemas de alto nível.

A única razão pela qual classes de exceção personalizadas detalhadas parece fazer sentido em sua amostra é porque (e aqui estou repetindo os outros entrevistados) - você não deve usar o tratamento de exceções para o fluxo de controle comum.

Uma alternativa inexplorada. Você pode estar modelando a coisa errada com suas aulas, e se você as tivesse?

public interface OpenDoor
{
    public ClosedDoor close();
    public LockedDoor lock();
}

public interface ClosedDoor
{
    public OpenDoor open();
    public LockedDoor lock();
}

public interface LockedDoor
{
    // ? unlock? open?
}

Agora é impossível tentar qualquer coisa que seja um erro. Você não precisa de nenhuma exceção.

Responderei à pergunta original, em vez de criticar o exemplo.

Simplificando, se você espera que o cliente precise reagir de maneira diferente para cada caso, ele garante um novo tipo de exceção.

Se você decidir usar vários tipos de exceção e, no entanto, esperar que, em alguns casos, o cliente queira criar uma cláusula de captura comum para eles, provavelmente crie uma superclasse abstrata que os dois estendem.

Este é um pseudocódigo, mas acho que você entenderá o que quero dizer:

public interface DoorService
{
    // ensures the door is open, uses key if locked, returns false if lock without a key or key does not fit
    bool Open(Door door, optional Key key) throws DoorStuckException, HouseOnFireException;

    // closes the door if open. already closed doors stay closed. Locked status does not change.
    void Close(Door door) throws throws DoorStuckException, HouseOnFireException;

    // closes the door if open and locks it
    void CloseAndLock(Door door, Key key) throws DoorStuckException, HouseOnFireException;
}

Sim, a reutilização do tipo de exceção faz sentido, se você usar exceções para coisas realmente excepcionais . Porque coisas verdadeiramente excepcionais são principalmente preocupações transversais. Você estava usando Exceções basicamente para controlar fluxos e isso leva a esses problemas.