Estendendo Exceção / RunTimeException em java?

Eu tenho aulas abaixo.

public class ValidationException extends RuntimeException { } 

e

 public class ValidationException extends Exception { } 

Estou confuso sobre quando a exceção personalizada deve estender o RunTimeException e quando ele precisa estender a Exception . Você poderia me explicar se há alguma desvantagem de estender o RunTimeException diretamente?

Obrigado!

RuntimeException estão desmarcados enquanto Exceção está marcada (o código de chamada deve manipulá-los).

A exceção personalizada deve estender RuntimeException se você quiser torná-lo desmarcado, caso contrário, estendê-lo com exceção.

Com exceções não verificadas, o método de código de chamada não é necessário para declarar em sua cláusula throws quaisquer subclasss de RuntimeException que possam ser lançadas durante a execução do método, mas não capturadas.

Como o método de chamada pode não manipular RuntimeException, é necessário ter cuidado ao lançar RuntimeException .

Exceções de tempo de execução representam problemas que são o resultado de um problema de programação e, como tal, o código do cliente da API não pode ser razoavelmente esperado para recuperar-se deles ou manipulá-los de qualquer maneira. Tais problemas incluem exceções aritméticas, como dividir por zero; exceções de ponteiro, como tentar acessar um object por meio de uma referência nula; e exceções de indexação, como tentar acessar um elemento de matriz por meio de um índice muito grande ou muito pequeno.

Exceções de tempo de execução podem ocorrer em qualquer lugar de um programa e, em um típico, podem ser muito numerosas. Ter de adicionar exceções de tempo de execução em cada declaração de método reduziria a clareza de um programa. Assim, o compilador não requer que você capture ou especifique exceções de tempo de execução (embora você possa).

Fonte / Leitura adicional: Exceções não verificadas – A controvérsia

Se você estender o RuntimeException , não precisará declará-lo na cláusula throws (ou seja, é uma exceção não verificada). Se você estender a exceção, você faz (é uma exceção verificada).

Algumas pessoas argumentam que todas as exceções devem se estender a partir de RuntimeException , mas se você quiser forçar o usuário a manipular a exceção, você deve estender a Exception .

Um caso em que é prática comum lançar um RuntimeException é quando o usuário chama um método incorretamente. Por exemplo, um método pode verificar se um dos seus argumentos é incorretamente nulo. Se um argumento for nulo, o método poderá lançar um NullPointerException, que é uma exceção não verificada.

De um modo geral, não lance uma RuntimeException ou crie uma subclass de RuntimeException simplesmente porque você não quer ser incomodado com a especificação das exceções que seus methods podem usar.

Aqui está a linha de base: Se um cliente puder se recuperar de uma exceção, faça uma exceção verificada. Se um cliente não puder fazer nada para recuperar-se da exceção, torne-a uma exceção não verificada.

para mais leia isto.

Definição de RuntimeException

RuntimeException é a superclass dessas exceções que podem ser lançadas durante a operação normal da Java Virtual Machine.

RuntimeException e suas subclasss são exceções não verificadas. Exceções não verificadas não precisam ser declaradas em um método ou na cláusula throws do construtor se elas puderem ser lançadas pela execução do método ou construtor e propagadas fora do limite do método ou do construtor.

Se você estender a Exception , você precisa pegar onde quer que você jogue sua ValidationException .

Se você estiver em uma estrutura de aplicativo e sua estrutura for boa para manipular a exceção quando houver uma notificação de exceção do seu código. Nesse caso, você pode usar sua class de exceção personalizada como subclass de RuntimeException.

Isso ajudará você a NÃO gravar o código para manipular a exceção através da hierarquia de exceções.