2

이 부분에서 초보자이므로 예외 처리에 finally 절을 사용하면 어떤 이점이 있습니다. 또는 다른 말로하면, 그것을 사용하는 것이 가장 좋은 때와 그것을 사용하지 않는 것이 가장 좋은 때입니다.예외 처리에서 "finally"절의 이점

내가 생각할 수있는 유일한 하나는 입/출력 스트림을 닫는 것입니다 ... 다른 이점은 무엇입니까 ??? !!

+0

로그, 실패 또는 성공 일지라도 실행하려는 프로세스 코드 – nachokk

+0

예를 들어 데이터베이스 삽입/업데이트/삭제 요청이 실패 할 때 트랜잭션을 롤백하는 것이 매우 유용 할 수 있습니다. – Kloe2378231

답변

1

StinePike가 작성한 것은 무엇이든 완벽하지만 그 안에 뭔가를 추가하고 싶습니다.

마지막으로 블록이 예외가 발생했는지 아닌지에 따라 실행됩니다. try 블록과 catch 블록()에서도 finally 블록 코드를 작성하여 finally 블록을 작성하지 않고이 작업을 수행 할 수 있습니다. 이제 예외가 발생하지 않으면 try 블록에서 코드를 실행합니다. 예외가 발생하면 catch 블록에서 코드를 실행합니다.

finally 블록의 추가 이점은 메소드의 어느 위치에서나 return 문을 쓸 수 있다는 것입니다. finally 블록이 실행되지만 finally 블록에 코드를 작성하지 않고 코드가 실행되지 않으면 코드가 실행되지 않습니다. 메서드 (어떤 조건을 기준으로)에 도달하기 전에.

+0

그레이트 ... 그러나 예외가 있었지만 finally 절에 코드의 나머지 부분을 임베딩하여 JVM을 트릭하고 프로그램을 완료하는 catch 절이 있습니다. –

+1

@Sofiane_AbuAmir ... 네, 그렇게 할 수 있습니다. 여전히 finally 블록이 실행되지만 예외가 catch 블록 중 하나에서 catch되지 않으므로 예외가 호출자 메서드에 발생합니다. 나는 당신이 많은 일을 할 수 있다고 말하고 싶지만 그것은 좋은 프로그래밍 스타일이 아니다. –

+0

@ Jatin Khurana .... 감사합니다 Jatin, 나도 그렇게 생각하고 있었지만 확실하지 않았습니다. –

5

finally은 입니다. 일부 리소스를 해제해야하는 경우에 유용합니다. 예를 들어

: 당신이 모든 작업이 완료 될 때마다 수행 할 작업의 모든 종류의

InputStream is = null; 
try { 
    is = new FileInputStream("C://test.txt"); 
    //some reading-file logic 
} catch (Exception e) { 
    //exception handling 
} finally { 
    //releasing the resources (closing the input stream) 
    if (is != null) { 
     is.close(); 
    } 
} 
+1

'is = ..'는 try 절 안에 있어야하며 java7 기능을 확인하십시오'resources with try' – nachokk

+2

닫기를 시도하기 전에 is == null에 대한 테스트를하는 것이 좋습니다. –

+0

감사합니다. :) –

2

는, finally 블록에 유용합니다. 여기서 마지막 작업으로 나는 모든 folowwings을 참조한다. 리소스를 해제하고, 스트림을 닫고, 모든 작업의 ​​종료 작업을 완료하십시오.

우리가 알고있는 것처럼 finally 블록은 예외가 있더라도 항상 실행됩니다. 따라서 finally 블록의 연산은 안정적입니다. 그래서 이것들이 마침내 이루어져야 할 과제들입니다.

1

이미 좋은 예를 생각해 보았습니다. I/O 스트림을 닫거나 더 일반적으로 이전에 생성/생성 한 모든 종류의 리소스를 해제하거나 해제합니다.

또 다른 예는 만들었던 프로세스/스레드를 종료시킬 수 있습니다.

클라이언트 구성 요소에 이벤트/알림을 보낼 수도 있습니다.

1

finally 유용한 또 다른 상황은 (내부적으로이 목적을 위해 finally를 사용하는 언어의 동기화 구조로 구현 잠금) "수동"잠금 해제 얻을 수 있도록하는 것입니다. 그러나이 작업을 수행 할 때 때때로 간과되는 세부 사항이 있습니다. 잠금은 코드가 객체의 불변성을 일시적으로 위반하게하고 다른 사람이 알아 차리기 전에 다시 설정하도록하기 위해 종종 획득됩니다. 객체의 불변 조건을 부적절한 상태로 남겨 두는 예외가 발생하면 적절한 동작은 일반적으로 잠금을 유지 된 상태로 두지 않고 변수가 발생했음을 나타내도록 설정하고 잠금을 획득 한 사람이이를 확인하도록합니다 변수가 설정되어 있으면 예외를 throw합니다. 보호 된 객체를 수정하지

void insertItem(...) 
{ 
    try 
    { 
    myLock.acquire(); 
    myLock.enterDanger(); 
    ... 
    myLock.leaveDanger(); 
    } 
    finally 
    { 
    myLock.release(); 
    } 
} 

코드 그러나 단순히이 "enterDanger"이 결코 읽

하나가 캡슐화 경우 잠금을-IS-유효 락 객체 내에서 변수, 코드처럼 보일 수 있습니다 .잠금이 여전히 danger 상태에있는 동안 release이 호출되면 현재 스택 추적을 캡처 할 수 있습니다. 보류 중이거나 이후에 myLock.acquire에 대한 호출은 예외를 던져야하며, 아마도 스택 추적을 보충 정보로 포함해야합니다. 하나 대신 시도 할 수있는 catch 블록 내에서 myLock을 무효화하는 것이 아니라 한 후 아무도 잠금을 무효화하지 않고 예상 예외를 처리하기 위해 try 블록에 catch 블록을 추가 없도록해야

참고. 예기치 않은 곳에서 예상 된 예외가 발생하면 보호 된 개체가 무효화 된 것으로 간주되는 catch을 트리거하지 않고 손상된 상태로 남을 수 있습니다.보다 구체적인 catch를 실행하면 덜 구체적인 예외가 실행되지 않습니다.

+0

위대한 예를 들자면 나는 그런 생각을하지 못했습니다. –