Respostas:
Geralmente RuntimeExceptions são exceções que podem ser evitadas por meio de programação. Por exemplo NullPointerException, ArrayIndexOutOfBoundException. Se você procurar nullantes de chamar qualquer método, NullPointerExceptionisso nunca ocorrerá. Da mesma forma ArrayIndexOutOfBoundException, nunca ocorreria se você verificar o índice primeiro. RuntimeExceptionnão são verificados pelo compilador, portanto, é um código limpo.
Edição : Hoje em dia as pessoas favorecem RuntimeExceptionporque o código limpo que produz. É uma escolha totalmente pessoal.
RuntimeExceptioné porque é simples e evita a necessidade de pensar nas diferenças entre exceções verificadas e não verificadas. Eu acho que pegar exceções de tempo de execução é uma péssima idéia, porque você vai pegar exceções irrecuperáveis, como NullPointerException.
Em Java, existem dois tipos de exceções: exceções verificadas e exceções não verificadas. Uma exceção verificada deve ser tratada explicitamente pelo código, enquanto que uma exceção não verificada não precisa ser explicitamente tratada.
Para exceções verificadas, é necessário colocar um bloco try / catch em torno do código que poderia gerar a exceção ou adicionar uma cláusula "throws" ao método, para indicar que o método pode lançar esse tipo de exceção (que deve ser manipulados na classe de chamada ou acima).
Qualquer exceção que deriva de "Exception" é uma exceção verificada, enquanto uma classe que deriva de RuntimeException é desmarcada. RuntimeExceptions não precisa ser explicitamente tratado pelo código de chamada.
Antes de observar a diferença entre java.lang.RuntimeExceptione java.lang.Exceptionclasses, você deve conhecer a Exceptionhierarquia. As classes Exceptione Errorsão derivadas da classe Throwable(que deriva da classe Object). E a classe RuntimeExceptioné derivada da classe Exception.
Todas as exceções são derivadas de Exceptionou RuntimeException.
Todas as exceções derivadas RuntimeExceptionsão chamadas de exceções não verificadas . E todas as outras exceções são exceções verificadas . Uma exceção verificada deve ser capturada em algum lugar do seu código, caso contrário, ela não será compilada. É por isso que eles são chamados de exceções verificadas. Por outro lado, com exceções não verificadas, o método de chamada não tem obrigação de manipular ou declarar.
Portanto, todas as exceções que o compilador obriga a manipular são derivadas diretamente java.lang.Exceptione todas as outras que o compilador não obriga a manipular são derivadas java.lang.RuntimeException.
A seguir, estão algumas das subclasses conhecidas diretas de RuntimeException .
AnnotationTypeMismatchException,
ArithmeticException,
ArrayStoreException,
BufferOverflowException,
BufferUnderflowException,
CannotRedoException,
CannotUndoException,
ClassCastException,
CMMException,
ConcurrentModificationException,
DataBindingException,
DOMException,
EmptyStackException,
EnumConstantNotPresentException,
EventException,
IllegalArgumentException,
IllegalMonitorStateException,
IllegalPathStateException,
IllegalStateException,
ImagingOpException,
IncompleteAnnotationException,
IndexOutOfBoundsException,
JMRuntimeException,
LSException,
MalformedParameterizedTypeException,
MirroredTypeException,
MirroredTypesException,
MissingResourceException,
NegativeArraySizeException,
NoSuchElementException,
NoSuchMechanismException,
NullPointerException,
ProfileDataException,
ProviderException,
RasterFormatException,
RejectedExecutionException,
SecurityException,
SystemException,
TypeConstraintException,
TypeNotPresentException,
UndeclaredThrowableException,
UnknownAnnotationValueException,
UnknownElementException,
UnknownTypeException,
UnmodifiableSetException,
UnsupportedOperationException,
WebServiceException Uma exceção está marcada e uma RuntimeException está desmarcada.
Verificado significa que o compilador exige que você lide com a exceção em uma captura ou declare seu método como lançá-la (ou uma de suas superclasses).
Geralmente, lance uma exceção verificada se o responsável pela chamada da API lidar com a exceção e uma exceção desmarcada se for algo que o responsável pela chamada normalmente não seria capaz de lidar, como um erro em um dos parâmetros, ou seja, uma programação erro.
As classes de exceção de tempo de execução (RuntimeException e suas subclasses) estão isentas da verificação em tempo de compilação, pois o compilador não pode estabelecer que exceções em tempo de execução não possam ocorrer. (de JLS).
Nas classes projetadas, você deve subclassar Exception e lançar instâncias para sinalizar quaisquer cenários excepcionais. Ao fazer isso, você estará sinalizando explicitamente aos clientes da sua classe que o uso da sua classe pode gerar uma exceção e eles precisam tomar medidas para lidar com esses cenários excepcionais.
Os trechos de código abaixo explicam este ponto:
//Create your own exception class subclassing from Exception
class MyException extends Exception {
public MyException(final String message) {
super(message);
}
}
public class Process {
public void execute() {
throw new RuntimeException("Runtime");
}
public void process() throws MyException {
throw new MyException("Checked");
}
}Na definição de classe acima da classe Process , o método executepode lançar uma RuntimeException, mas a declaração do método não precisa especificar que ela lança RuntimeException .
O método processlança uma exceção verificada e deve declarar que lançará uma exceção verificada do tipo MyException e, caso contrário, será um erro de compilação.
A definição de classe acima afetará o código que também usa a classe Process .
A chamada new Process().execute()é uma chamada válida, na qual, como a chamada do formulário
new Process().process()gera um erro de compilação. Isso ocorre porque o código do cliente deve executar etapas para manipular MyException(digamos, chamada para process () pode ser incluída em um bloco try / catch).
Uso adequado de RuntimeException?
Das exceções não verificadas - a controvérsia :
Se for razoável esperar que um cliente se recupere de uma exceção, torne-a uma exceção verificada. Se um cliente não puder fazer nada para se recuperar da exceção, torne-a uma exceção desmarcada.
Observe que uma exceção não marcada é uma derivada RuntimeExceptione uma exceção verificada é uma derivada Exception.
Por que lançar um RuntimeExceptionse um cliente não pode fazer nada para se recuperar da exceção? O artigo explica:
As exceções de tempo de execução representam problemas resultantes de um problema de programação e, como tal, não é de esperar que o código do cliente da API se recupere deles ou os manipule de qualquer maneira. Tais problemas incluem exceções aritméticas, como dividir por zero; exceções de ponteiro, como tentar acessar um objeto através de uma referência nula; e exceções de indexação, como tentar acessar um elemento da matriz por meio de um índice que é muito grande ou muito pequeno.
Da documentação do oracle:
Aqui está a orientação: se um cliente puder razoavelmente se recuperar de uma exceção, torne-a uma exceção verificada. Se um cliente não puder fazer nada para se recuperar da exceção, torne-a uma exceção desmarcada.
As exceções de tempo de execução representam problemas resultantes de um problema de programação e, como tal, não é de esperar que o código do cliente da API se recupere deles ou os manipule de qualquer maneira.
RuntimeExceptions são como "exceções pelo uso inválido de uma API" exemplos de exceções de execução: IllegalStateException, NegativeArraySizeException, NullpointerException
Com as exceções, você deve capturá-lo explicitamente porque ainda pode fazer algo para se recuperar. Exemplos de exceções são: IOException, TimeoutException, PrintException ...
Em palavras simples, se seu cliente / usuário puder se recuperar da Exceção, torne-a uma Exceção Verificada , se seu cliente não puder fazer nada para se recuperar da Exceção, faça-o como Desmarcado RuntimeException . Por exemplo, uma RuntimeException seria um erro programático, como divisão por zero, nenhum usuário pode fazer nada a não ser o próprio programador, então é uma RuntimeException .
RuntimeException é uma classe filho da classe Exception
Essa é uma das muitas classes filho da classe Exception. RuntimeException é a superclasse dessas exceções que podem ser lançadas durante a operação normal da Java Virtual Machine. Não é necessário que um método declare em sua cláusula throws quaisquer subclasses de RuntimeException que possam ser lançadas durante a execução do método, mas não capturadas.
A hierarquia é
java.lang.Object
--- java.lang.Throwable
------- java.lang.Exception
------------- java.lang.RuntimeException
As exceções são uma boa maneira de lidar com eventos inesperados no fluxo do aplicativo. RuntimeException não está marcado pelo Compilador, mas você pode preferir usar Exceções que estendem a Classe de Exceção para controlar o comportamento de seus clientes API, pois são necessários para detectar erros para compilação. Também forma uma boa documentação.
Se desejar obter uma interface limpa, use herança para subclassificar os diferentes tipos de exceção que seu aplicativo possui e, em seguida, exponha a exceção pai.
Existem dois tipos de exceção: você pode se recuperar da exceção verificada se receber esse tipo de exceção. Exceções de tempo de execução são irrecuperáveis, exceções de tempo de execução são erros de programação, e o programador deve cuidar disso enquanto escreve o código, e continuar a execução disso pode resultar em resultados incorretos. As exceções de tempo de execução são sobre violar a pré-condição ex. você tem uma matriz de tamanho 10 e está tentando acessar o 11º elemento, ele lançará ArrayIndexOutOfBoundException
A exceção definida pelo usuário pode ser exceção verificada ou exceção não verificada, depende da classe para a qual está estendendo.
A exceção definida pelo usuário pode ser uma exceção verificada personalizada, se estiver estendendo para a classe Exception
Exceção definida pelo usuário pode ser Exceção não verificada personalizada, se estiver estendendo para a classe Exceção de tempo de execução.
Defina uma classe e torne-a filha de Exception ou Run time Exception