자바에서 확인 된 예외와 확인되지 않은 예외 이해

자바에서 확인 된 예외와 확인되지 않은 예외 이해

---

" Effective Java "의 Joshua Bloch는 다음과 같이 말했습니다.

복구 가능한 조건에 대해 검사 된 예외를 사용하고 프로그래밍 오류에 대해 런타임 예외를 사용합니다 (제 2 판의 항목 58).

내가 이것을 올바르게 이해하는지 보자.

확인 된 예외에 대한 나의 이해는 다음과 같습니다.

try{
    String userInput = //read in user input
    Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
    id = 0; //recover the situation by setting the id to 0
}

1. 위의 사항이 확인 된 예외로 간주됩니까?

2. RuntimeException이 확인되지 않은 예외입니까?

확인되지 않은 예외에 대한 나의 이해는 다음과 같습니다.

try{
    File file = new File("my/file/path");
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){

//3. What should I do here?
    //Should I "throw new FileNotFoundException("File not found");"?
    //Should I log?
    //Or should I System.exit(0);?
}

4. 이제 위의 코드도 검사 예외가 될 수 없습니까? 이런 상황을 복구 할 수 있을까요? 할 수 있습니까? (참고 : 세 번째 질문은 catch위에 있습니다)

try{
    String filePath = //read in from user input file path
    File file = new File(filePath);
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){
    //Kindly prompt the user an error message
    //Somehow ask the user to re-enter the file path.
}

5. 사람들이 이것을하는 이유는 무엇입니까?

public void someMethod throws Exception{

}

예외가 발생하는 이유는 무엇입니까? 오류를 더 빨리 처리하지 않습니까? 왜 거품이 일어?

6. 정확한 예외를 표시하거나 예외를 사용하여 마스크해야합니까?

아래는 내 독서입니다

Java에서 확인 된 예외는 언제 생성해야하며 런타임 예외 여야합니까?

선택 및 선택되지 않은 예외를 선택하는 경우

---

많은 사람들은 체크 된 예외 (즉, 명시 적으로 포착하거나 다시 던져야하는 예외)를 전혀 사용해서는 안된다고 말합니다. 예를 들어 C #에서는 제거되었으며 대부분의 언어에는 없습니다. 따라서 항상 RuntimeException(확인되지 ​​않은 예외) 의 하위 클래스를 던질 수 있습니다.

그러나 확인 된 예외는 유용하다고 생각합니다. API 사용자가 예외 상황을 처리하는 방법을 생각하도록 강제하려는 경우 (복구 가능한 경우) 사용됩니다. 확인 된 예외가 Java 플랫폼에서 과도하게 사용되어 사람들이 싫어하는 것입니다.

여기에 주제에 대한 나의 확장 된 견해가 있습니다 .

특정 질문에 관해서는 :

1. 는 NumberFormatException체크 예외를 고려?
   아니요 NumberFormatException는 선택되지 않았습니다 (=는의 하위 클래스 임 RuntimeException). 왜? 모르겠어요. (그러나 방법이 있었어야했다 isValidInteger(..))

2. 가 RuntimeException체크되지 않은 예외?
   네, 맞습니다.

3. 여기서 무엇을해야합니까?
   이 코드의 위치와 원하는 작업에 따라 다릅니다. UI 레이어에있는 경우-잡아서 경고를 표시합니다. 그것이 서비스 계층에 있다면-전혀 포착하지 마십시오. 예외를 삼키지 마십시오. 대부분의 경우 예외가 발생하면 다음 중 하나를 선택해야합니다.

   • 그것을 기록하고 반환
   • 다시 던짐 (메서드에서 던지도록 선언)
   • 생성자에서 현재 예외를 전달하여 새 예외를 생성합니다.

4. 자, 위의 코드도 검사 예외가 될 수 없습니까? 이런 상황을 복구 할 수 있을까요? 할 수 있습니까?
   그럴 수도 있습니다. 그러나 확인되지 않은 예외도 잡는 것을 막을 수는 없습니다.

5. 사람들 Exception이 throws 절에 클래스 를 추가하는 이유는 무엇 입니까?
   대부분 사람들은 무엇을 잡을지, 무엇을 다시 던질 지 생각하기가 게으 르기 때문입니다. 던지는 Exception것은 나쁜 습관이므로 피해야합니다.

아아, 잡을 때, 다시 던질 때, 체크를 사용할 때, 체크되지 않은 예외를 사용할 때를 결정할 수있는 단일 규칙은 없습니다. 나는 이것이 많은 혼란과 많은 나쁜 코드를 야기한다는 것에 동의합니다. 일반적인 원칙은 Bloch에 의해 명시되어 있습니다 (일부 인용). 그리고 일반적인 원칙은 처리 할 수있는 계층에 예외를 다시 던지는 것입니다.

---

어떤 것이 "체크 된 예외"인지 여부는이를 포착하는지 또는 catch 블록에서 수행하는 작업과 관련이 없습니다. 예외 클래스의 속성입니다. 의 서브 클래스를 아무거나 Exception 제외 에 RuntimeException와 그 서브 클래스는 체크 예외입니다.

Java 컴파일러는 확인 된 예외를 포착하거나 메소드 서명에서 선언하도록 강제합니다. 프로그램 안전성을 향상시키기위한 것이었지만 대부분의 의견은 그것이 생성하는 디자인 문제의 가치가 없다는 것입니다.

예외가 발생하는 이유는 무엇입니까? 오류를 처리할수록 빠를수록 좋습니다. 왜 거품이 일어?

그것이 예외 의 전체 포인트 이기 때문 입니다. 이 가능성이 없으면 예외가 필요하지 않습니다. 이를 통해 오류가 원래 발생하는 저수준 방법으로 처리하도록 강요하지 않고 선택한 수준에서 오류를 처리 할 수 ​​있습니다.

---

1. 위의 사항이 확인 된 예외로 간주됩니까? 아니요 예외를 처리하고 Checked Exception있다고해서 RuntimeException.

2. 가 RuntimeException은 unchecked exception? 예

Checked Exceptions이다 subclasses의 java.lang.Exception Unchecked Exceptions이다 subclasses의java.lang.RuntimeException

확인 된 예외를 발생시키는 호출은 try {} 블록에 포함되거나 메서드 호출자의 상위 수준에서 처리되어야합니다. 이 경우 현재 메서드는 호출자가 예외를 처리하기위한 적절한 준비를 할 수 있도록 해당 예외를 throw한다고 선언해야합니다.

도움이 되었기를 바랍니다.

Q : 정확한 예외를 표시하거나 예외를 사용하여 마스킹해야합니까?

A : 예, 이것은 매우 좋은 질문이며 중요한 설계 고려 사항입니다. Exception 클래스는 매우 일반적인 예외 클래스이며 내부 저수준 예외를 래핑하는 데 사용할 수 있습니다. 사용자 지정 예외를 만들고 그 안에 래핑하는 것이 좋습니다. 그러나 큰 문제는 근본적인 근본 원인을 결코 모호하게하지 않습니다. 예를 들어, Don't ever다음을 수행하십시오-

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

대신 다음을 수행하십시오.

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

원래의 근본 원인을 제거하는 것은 복구 이상의 실제 원인을 묻히는 것은 애플리케이션 로그와 오류 메시지 만 액세스 할 수있는 프로덕션 지원 팀에게 악몽입니다. 후자가 더 나은 디자인이지만 개발자가 기본 메시지를 호출자에게 전달하지 못하기 때문에 많은 사람들이 자주 사용하지 않습니다. 따라서 확고한 메모를 작성하십시오. Always pass on the actual exception애플리케이션 특정 예외에 래핑되었는지 여부를 다시 확인 하십시오 .

시도 잡기 RuntimeExceptions

RuntimeExceptions는 일반적으로 try-catch해서는 안됩니다. 일반적으로 프로그래밍 오류를 나타내며 그대로 두어야합니다. 대신 프로그래머는 RuntimeException. 예 :

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

이것은 잘못된 프로그래밍 관행입니다. 대신 null 검사는 다음과 같이 수행되어야합니다.

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

그러나 숫자 형식화와 같이 이러한 오류 검사에 비용이 많이 드는 경우가 있습니다.

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

여기서 사전 호출 오류 검사는 본질적으로 parseInt () 메서드 내에서 모든 문자열-정수 변환 코드를 복제하는 것을 의미하기 때문에 노력할 가치가 없으며 개발자가 구현하면 오류가 발생하기 쉽습니다. 따라서 try-catch를 사용하지 않는 것이 좋습니다.

그래서 NullPointerException그리고 NumberFormatException둘 다 RuntimeExceptions, 오류가 발생하기 쉬운 코드의 도입 가능성을 피하기 위해 명시 적으로 NullPointerException잡는 것이 좋습니다 NumberFormatException.

---

1 . 예외에 대해 확실하지 않은 경우 API를 확인하십시오.

 java.lang.Object
 extended by java.lang.Throwable
  extended by java.lang.Exception
   extended by java.lang.RuntimeException  //<-NumberFormatException is a RuntimeException  
    extended by java.lang.IllegalArgumentException
     extended by java.lang.NumberFormatException

2. 예, 그리고 그것을 확장하는 모든 예외.

삼 . 같은 예외를 잡아서 던질 필요가 없습니다. 이 경우 새 파일 대화 상자를 표시 할 수 있습니다.

4. FileNotFoundException 은 이미 확인 된 예외입니다.

5. someMethod예외를 포착하기 위해 호출하는 메서드가 예상되는 경우 후자가 throw 될 수 있습니다. 그것은 단지 "공을 통과"합니다. 사용의 예는 자신의 개인 메서드에 던지고 대신 공용 메서드에서 예외를 처리하려는 경우입니다.

좋은 읽기는 Oracle 문서 자체입니다 : http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html

디자이너가 범위 내에서 발생할 수있는 잡히지 않은 모든 확인 된 예외를 지정하도록 메서드를 강제로 결정한 이유는 무엇입니까? 메서드에 의해 throw 될 수있는 모든 예외는 메서드의 공용 프로그래밍 인터페이스의 일부입니다. 메서드를 호출하는 사람은 메서드가 throw 할 수있는 예외에 대해 알고 있어야 처리 방법을 결정할 수 있습니다. 이러한 예외는 매개 변수 및 반환 값만큼 해당 메서드의 프로그래밍 인터페이스의 일부입니다.

다음 질문은 다음과 같습니다. "발생할 수있는 예외를 포함하여 메서드의 API를 문서화하는 것이 좋은 경우 런타임 예외도 지정하지 않는 이유는 무엇입니까?" 런타임 예외는 프로그래밍 문제의 결과 인 문제를 나타내므로 API 클라이언트 코드는 이러한 문제로부터 복구하거나 어떤 방식 으로든 처리 할 수 ​​없습니다. 이러한 문제에는 0으로 나누기와 같은 산술 예외가 포함됩니다. null 참조를 통해 객체에 액세스하려는 것과 같은 포인터 예외 및 너무 크거나 너무 작은 인덱스를 통해 배열 요소에 액세스하려는 시도와 같은 인덱싱 예외.

Java 언어 사양 에도 중요한 정보가 있습니다 .

throws 절에 명명 된 확인 된 예외 클래스는 메서드 또는 생성자의 구현 자와 사용자 간의 계약의 일부입니다 .

IMHO의 요점은 모든를 잡을 수 있다는 것입니다 RuntimeException. 그러나 반드시 그럴 필요는 없으며 실제로 구현은 계약의 일부가 아니므로 확인되지 않은 동일한 예외를 유지할 필요가 없습니다.

---

1) 아니요, NumberFormatException은 확인되지 않은 예외입니다. 확인되지 않았기 때문에 잡았더라도 (필수는 아님). 이는의 하위 클래스 인 하위 클래스이기 때문 IllegalArgumentException입니다 RuntimeException.

2) RuntimeException는 확인되지 않은 모든 예외의 루트입니다. 의 모든 하위 클래스 RuntimeException는 선택 취소됩니다. 기타 모든 예외 Throwable는 오류 (아래에 있음 Throwable)를 제외하고 확인 됩니다.

3/4) 사용자에게 존재하지 않는 파일을 선택했음을 알리고 새 파일을 요청할 수 있습니다. 또는 사용자에게 잘못된 것을 입력했음을 알리는 것을 중단하십시오.

5) 던지고 잡는 'Exception'것은 나쁜 습관입니다. 그러나 더 일반적으로 호출자가 처리 방법을 결정할 수 있도록 다른 예외를 throw 할 수 있습니다. 예를 들어, 일부 파일 입력 읽기를 처리하기 위해 라이브러리를 작성했고 메서드가 존재하지 않는 파일을 전달받은 경우이를 처리하는 방법을 알 수 없습니다. 발신자가 다시 묻거나 종료할까요? 따라서 Exception을 체인 위로 다시 호출자에게 던집니다.

대부분의 경우 unchecked Exception프로그래머가 입력을 확인하지 않았기 때문에 발생합니다 ( NumberFormatException첫 번째 질문 의 경우 ). 그렇기 때문에 이러한 예외를 생성하지 않는 더 우아한 방법이 있기 때문에이를 포착하는 것이 선택 사항입니다.

---

확인 됨-발생하기 쉽습니다. 컴파일 시간에 확인되었습니다.

예 : FileOperations

확인되지 않음-잘못된 데이터로 인해. 런타임에 체크인했습니다.

예 ..

String s = "abc";
Object o = s;
Integer i = (Integer) o;

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
    at Sample.main(Sample.java:9)

여기서 예외는 잘못된 데이터로 인한 것이며 컴파일 시간 동안 확인할 수 없습니다.

---

확인 된 예외는 JVM 및 리소스 (files / db / stream / socket 등)와 관련된 컴파일 시간에 확인됩니다. 확인 된 예외의 동기는 리소스를 사용할 수없는 경우 컴파일 타임에 응용 프로그램이 catch / finally 블록에서이를 처리하기위한 대체 동작을 정의해야한다는 것입니다.

확인되지 않은 예외는 순전히 프로그래밍 오류, 잘못된 계산, null 데이터 또는 비즈니스 논리의 실패로 인해 런타임 예외가 발생할 수 있습니다. 코드에서 확인되지 않은 예외를 처리 / 캐치하는 것은 절대적으로 괜찮습니다.

http://coder2design.com/java-interview-questions/ 에서 가져온 설명

---

확인되지 않은 예외와 확인 된 예외의 차이점에 대한 제가 가장 좋아하는 설명은 Java Tutorial 트레일 기사 인 " Unchecked Exceptions-the Controversy "(이 게시물에 대한 모든 기본 사항을 알려 드리게되어 죄송합니다.하지만 기본 사항이 때로는 최고입니다) :

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception

The heart of "what type of exception to throw" is semantic (to some degree) and the above quote provides and excellent guideline (hence, I am still blown away by the notion that C# got rid of checked exceptions - particularly as Liskov argues for their usefulness).

The rest then becomes logical: to which exceptions does the compiler expect me to respond, explicitly? The ones from which you expect client to recover.

---

Runtime Exceptions Runtime exceptions are referred to as unchecked exceptions. All other exceptions are checked exceptions, and they don't derive from java.lang.RuntimeException.

Checked Exceptions A checked exception must be caught somewhere in your code. If you invoke a method that throws a checked exception but you don't catch the checked exception somewhere, your code will not compile. That's why they're called checked exceptions: the compiler checks to make sure that they're handled or declared.

A number of the methods in the Java API throw checked exceptions, so you will often write exception handlers to cope with exceptions generated by methods you didn't write.

---

To answer the final question (the others seem thoroughly answered above), "Should I bubble up the exact exception or mask it using Exception?"

I am assuming you mean something like this:

public void myMethod() throws Exception {
    // ... something that throws FileNotFoundException ...
}

No, always declare the most precise exception possible, or a list of such. The exceptions you declare your method as capable of throwing are a part of the contract between your method and the caller. Throwing "FileNotFoundException" means that it is possible the file name isn't valid and the file will not be found; the caller will need to handle that intelligently. Throwing Exception means "Hey, sh*t happens. Deal." Which is a very poor API.

In the comments on the first article there are some examples where "throws Exception" is a valid and reasonable declaration, but that's not the case for most "normal" code you will ever write.

---

I just want to add some reasoning for not using checked exceptions at all. This is not a full answer, but I feel it does answer part of your question, and complements many other answers.

Whenever checked exceptions are involved, there's a throws CheckedException somewhere in a method signature (CheckedException could be any checked exception). A signature does NOT throw an Exception, throwing Exceptions is an aspect of implementation. Interfaces, method signatures, parent classes, all these things should NOT depend on their implementations. The usage of checked Exceptions here (actually the fact that you have to declare the throws in the method signature) is binding your higher-level interfaces with your implementations of these interfaces.

Let me show you an example.

Let's have a nice and clean interface like this

public interface IFoo {
    public void foo();
}

Now we can write many implementations of method foo(), like these

public class Foo implements IFoo {
    @Override
    public void foo() {
        System.out.println("I don't throw and exception");
    }
}

Class Foo is perfectly fine. Now let's make a first attempt at class Bar

public class Bar implements IFoo {
    @Override
    public void foo() {
        //I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
        throw new InterruptedException();
    }
}

This class Bar won't compile. As InterruptedException is a checked exception, you must either capture it (with a try-catch inside method foo()) or declare that you're throwing it (adding throws InterruptedException to the method signature). As I don't want to capture this exception here (I want it to propagate upwards so I can properly deal with it somewhere else), let's alter the signature.

public class Bar implements IFoo {
    @Override
    public void foo() throws InterruptedException {
        throw new InterruptedException();
    }
}

This class Bar won't compile either! Bar's method foo() does NOT override IFoo's method foo() since their signatures are different. I could remove the @Override annotation, but I want to program against interface IFoo like IFoo foo; and later on decide on which implementation I want to use, like foo = new Bar();. If Bar's method foo() doesn't override IFoo's method foo, when I do foo.foo(); it won't call Bar's implementation of foo().

To make Bar's public void foo() throws InterruptedException override IFoo's public void foo() I MUST add throws InterruptedException to IFoo's method signature. This, however, will cause problems with my Foo class, since it's foo() method's signature differs from IFoo's method signature. Furthermore, if I added throws InterruptedException to Foo's method foo() I would get another error stating that Foo's method foo() declares that it throws an InterruptedException yet it never throws an InterruptedException.

As you can see (if I did a decent job at explaining this stuff), the fact that I'm throwing a checked exception like InterruptedException is forcing me to tie my interface IFoo to one of it's implementations, which in turn causes havoc on IFoo's other implementations!

This is one big reason why checked exceptions are BAD. In caps.

One solution is to capture the checked exception, wrap it in an unchecked exception and throw the unchecked exception.

---

• Java distinguishes between two categories of exceptions (checked & unchecked).
• Java enforces a catch or declared requirement for checked exceptions.
• An exception's type determines whether an exception is checked or unchecked.
• All exception types that are direct or indirect subclasses of class RuntimeException are unchecked exception.
• All classes that inherit from class Exception but not RuntimeException are considered to be checked exceptions.
• Classes that inherit from class Error are considered to be unchecked.
• Compiler checks each method call and deceleration to determine whether the method throws checked exception.
  • If so the compiler ensures the exception is caught or is declared in a throws clause.
• To satisfy the declare part of the catch-or-declare requirement, the method that generates the exception must provide a throws clause containing the checked-exception.
• Exception classes are defined to be checked when they are considered important enough to catch or declare.

---

Here is a simple rule that can help you decide. It is related to how interfaces are used in Java.

Take your class and imagine designing an interface for it such that the interface describes the functionality of the class but none of the underlying implementation (as an interface should). Pretend perhaps that you might implement the class in another way.

Look at the methods of the interface and consider the exceptions they might throw:

If an exception can be thrown by a method, regardless of the underlying implementation (in other words, it describes the functionality only) then it should probably be a checked exception in the interface.

If an exception is caused by the underlying implementation, it should not be in the interface. Therefore, it must either be an unchecked exception in your class (since unchecked exceptions need not appear in the interface signature), or you must wrap it and rethrow as a checked exception that is part of the interface method.

To decide if you should wrap and rethrow, you should again consider whether it makes sense for a user of the interface to have to handle the exception condition immediately, or the exception is so general that there is nothing you can do about it and it should propagate up the stack. Does the wrapped exception make sense when expressed as functionality of the new interface you are defining or is it just a carrier for a bag of possible error conditions that could also happen to other methods? If the former, it might still be a checked exception, otherwise it should be unchecked.

You should not usually plan to "bubble-up" exceptions (catch and rethrow). Either an exception should be handled by the caller (in which case it is checked) or it should go all the way up to a high level handler (in which case it is easiest if it is unchecked).

---

Why do they let the exception bubble up? Isn't handling the error sooner better? Why bubble up?

For example let say you have some client-server application and client had made a request for some resource that couldn't be find out or for something else error some might have occurred at the server side while processing the user request then it is the duty of the server to tell the client why he couldn't get the thing he requested for,so to achieve that at server side, code is written to throw the exception using throw keyword instead of swallowing or handling it.if server handles it/swallow it, then there will be no chance of intimating to the client that what error had occurred.

Note:To give a clear description of what the error type has occurred we can create our own Exception object and throw it to the client.

---

I think that checked exceptions are a good reminder for the developer that uses an external library that things can go wrong with the code from that library in exceptional situations.

Read more about checked vs unchecked exceptions here http://learnjava.today/2015/11/checked-vs-unchecked-exceptions/

---

Just to point out that if you throw a checked exception in a code and the catch is few levels above, you need to declare the exception in the signature of each method between you and the catch. So, encapsulation is broken because all functions in the path of throw must know about details of that exception.

---

In short, exceptions which your module or modules above are supposed to handle during runtime are called checked exceptions; others are unchecked exceptions which are either RuntimeException or Error.

In this video, it explains checked and unchecked exceptions in Java:
https://www.youtube.com/watch?v=ue2pOqLaArw

---

All of those are checked exceptions. Unchecked exceptions are subclasses of RuntimeException. The decision is not how to handle them, it's should your code throw them. If you don't want the compiler telling you that you haven't handled an exception then you use an unchecked (subclass of RuntimeException) exception. Those should be saved for situations that you can't recover from, like out of memory errors and the like.

---

If anybody cares for yet another proof to dislike checked exceptions, see the first few paragraphs of the popular JSON library:

"Although this is a checked exception, it is rarely recoverable. Most callers should simply wrap this exception in an unchecked exception and rethrow: "

So why in the world would anyone make developers keep checking the exception, if we should "simply wrap it" instead? lol

http://developer.android.com/reference/org/json/JSONException.html

---

Checked Exceptions :

• The exceptions which are checked by the compiler for smooth execution of the program at runtime are called Checked Exception.

• These occur at compile time.

• If these are not handled properly, they will give compile time error (Not Exception).

• All subclasses of Exception class except RuntimeException are Checked Exception.

  Hypothetical Example - Suppose you are leaving your house for the exam, but if you check whether you took your Hall Ticket at home(compile time) then there won't be any problem at Exam Hall(runtime).

Unchecked Exception :

• The exceptions which are not checked by the compiler are called Unchecked Exceptions.

• These occur at runtime.

• If these exceptions are not handled properly, they don’t give compile time error. But the program will be terminated prematurely at runtime.

• All subclasses of RunTimeException and Error are unchecked exceptions.

  Hypothetical Example - Suppose you are in your exam hall but somehow your school had a fire accident (means at runtime) where you can't do anything at that time but precautions can be made before (compile time).

---

All exceptions must be checked exceptions.

1. Unchecked exceptions are unrestricted gotos. And unrestricted gotos are considered a bad thing.

2. Unchecked exceptions break encapsulation. To process them correctly, all the functions in the call tree between the thrower and the catcher must be known to avoid bugs.

3. Exceptions are errors in the function that throws them but not errors in the function that processes them. The purpose of exceptions is to give the program a second chance by deferring the decision of whether it's an error or not to another context. It's only in the other context can the correct decision be made.

참고URL : https://stackoverflow.com/questions/6115896/understanding-checked-vs-unchecked-exceptions-in-java