Преимущества предложения «finally» в обработке исключений

Question

Будучи новичком в этом, в чем преимущества использования предложения в обработке исключений. Или другими словами, когда лучше использовать его и когда лучше не использовать его.

Единственное, что я могу придумать, это закрыть поток ввода/вывода ... любые другие преимущества ??? !!

Answer 1

Все, что написал StinePike, идеально подходит, но я хочу добавить что-то в этом.

Окончательный блок выполняется либо с исключением, либо с ошибкой .... поэтому мы можем достичь этого без окончательного блока, написав код блока finally в блоке try, а также в catch catch(). Теперь, если исключение не происходит, оно выполняет код из блока try.If возникает исключение, он выполняет код из блока catch.

Таким образом, дополнительное преимущество блока finally состоит в том, что вы можете писать оператор возврата в любом месте метода, но, тем не менее, блок выполняется, но код не выполняется, если вы не записываете код в блок finally и возвращаете его из метод (на основе некоторого условия) до достижения этого кода.

Answer 2

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(); 
    } 
} 

Answer 3

Для любого рода задач, которые вы хотите сделать, когда все задачи закончены, наконец, блок полезен. Здесь по заключительным задачам я отношусь к любому из этих слов. освобождение ресурсов, закрытие потоков, завершение ваших конечных задач любых операций и т. д.

Как известно, блок finally всегда выполняется даже после любого исключения. поэтому операции в блоке finally исполняются. поэтому эти задачи должны быть выполнены в конечном итоге.

Answer 4

Вы уже подумали о хорошем примере. Закрытие потоков ввода-вывода или, в общем, освобождение/освобождение любого ресурса, который вы ранее открывали/создавали.

Другим примером может быть завершение процесса/потока, который вы, возможно, создали.

Более того, вы можете отправлять события/уведомления клиентским компонентам.

Answer 5

Другая ситуация, при которой finally является полезной, заключается в том, чтобы обеспечить освобождение «ручных» замков (для этой цели предусмотрены блокировки, реализованные с синхронизирующими структурами языка, для этого используются finally). Тем не менее, при выполнении этой функции иногда возникает недоумение: блокировки часто приобретаются для того, чтобы позволить коду мгновенно нарушать инварианты объекта и восстанавливать их, прежде чем кто-либо еще сможет заметить. Если возникает исключение, которое оставило бы инварианты объекта в ненадлежащем состоянии, правильное поведение, как правило, не должно оставлять блокировку, но, скорее, убедитесь, что переменная установлена, чтобы указать, что произошло, и кто-нибудь, кто приобретает блокировку, проверяет это переменную и выставить исключение, если оно установлено.

Если один инкапсулирует замок-это-действует переменный в пределах объекта блокировки, код может выглядеть следующим образом:

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

кодекса, который никогда не модифицирует охраняемый объект, а просто читает его никогда не придется «enterDanger» ,Если release вызывается, пока замок все еще находится в состоянии danger, он может захотеть захватить текущую трассировку стека; ожидающие или будущие звонки в myLock.acquire должны генерировать исключение, возможно, включая трассировку стека в качестве дополнительной информации.

Обратите внимание, что можно было бы попробовать вместо того, чтобы аннулировать myLock в catch блоке, но один должен затем убедиться, что никто не добавляет catch блок к блоку try обрабатывать ожидаемые исключения без нарушения блокировки. Если ожидаемое исключение происходит в непредвиденном месте, охраняемый объект может быть оставлен в коррумпированном состоянии без запуска catch, который должен был аннулировать его (выполнение более конкретного улова предотвратит выполнение менее специфического).