"catch"없이 "try-finally"를 수행하는 것이 합리적입니까?

다음과 같은 코드를 보았습니다.

    try
    {
        db.store(mydata);
    }
    finally
    {
        db.cleanup();
    }

나는 try있어야한다고 생각 catch?

이 코드가 이런 식으로하는 이유는 무엇입니까?

이는 현재 실행중인 메서드가 리소스를 적절하게 정리할 수 있도록 허용하면서 여전히 예외를 throw하도록하려는 경우 유용합니다. 다음은 호출 메서드에서 예외를 처리하는 구체적인 예입니다.

public void yourOtherMethod() {
    try {
        yourMethod();
    } catch (YourException ex) {
        // handle exception
    }
}    

public void yourMethod() throws YourException {
    try {
        db.store(mydata);
    } finally {
        db.cleanup();
    }
}

프로그래머가 db.cleanup()try 블록 내부의 코드에서 예외가 발생하더라도 호출 되는지 확인하기를 원했기 때문 입니다. 모든 예외는 해당 블록에 의해 처리되지 않지만 finally 블록이 실행 된 후에 만 ​​위쪽으로 전파됩니다.

이 코드가 이런 식으로하는 이유는 무엇입니까?

분명히 코드는이 수준에서 예외를 처리하는 방법을 모르기 때문입니다. 괜찮 습니다. 호출자 중 한 명이하는 한, 즉 예외가 궁극적으로 어딘가에서 처리되는 한.

종종 사용자에게 알림을 보내야하거나 예외를 기록해야하거나 다른 전략을 시도해야하기 때문에 하위 수준 코드가 예외에 적절하게 반응 할 수 없습니다. 낮은 수준의 코드는 하나의 기능 만 수행 하고 높은 수준의 의사 결정에 대해 알지 못합니다.

그러나 코드는 여전히 리소스를 정리해야합니다 (그렇지 않으면 누출 될 수 있기 때문입니다). 따라서 예외가 발생했는지 여부에 관계없이 항상 발생 하도록 finally절 에서이를 수행 합니다.

finally 블록은 RuntimeException이 발생하더라도 (호출 된 코드의 일부 버그로 인해) db.cleanup()호출이 이루어 지도록합니다.

이것은 너무 많은 중첩을 방지하기 위해 자주 사용됩니다.

try
{
    if (foo) return false;
    //bla ...
    return true;
}
finally
{
    //clean up
}

특히 메서드가 반환하는 지점이 많은 경우 모든 경우에 정리 코드가 호출되는 것을 누구나 볼 수 있으므로 가독성이 향상됩니다.

코드는 데이터베이스가 닫혀 있는지 확인하기 위해 수행합니다.
일반적으로이를 수행하는 방법은 모든 데이터베이스 액세스 코드를 try 블록에 넣은 다음 finally 블록에서 데이터베이스를 닫도록 호출하는 것입니다.
try ... finally 작동 방식은 try 블록의 코드가 실행되고, 완료되면 finally 블록의 코드가 실행됩니다.
컴퓨터가 벽에서 잡아 당기지 않으면 마침내 실행됩니다.
즉, 예외가 호출되고 메서드가 실행되는 데 3 년이 걸리더라도 finally 블록에 남아 데이터베이스가 닫힙니다.

try 블록의 코드 중 하나라도 확인 된 예외를 throw 할 수있는 경우 메서드 서명의 throws 절에 나타나야합니다. 확인되지 않은 예외가 발생하면 메서드에서 버블 링됩니다.

finally 블록은 예외 발생 여부에 관계없이 항상 실행됩니다.