在 try catch/but finally 语句中 finally 的意义是什么

多年来，我一直在许多语言中使用 try-catch/竹篮打水一场空。今天有人问我 finally 的意义是什么，我无法回答。

基本上，为什么要在 finally 中放入一个语句，而不是仅仅将其放在 try-catch 块的后面呢？或者换句话说，以下代码块之间存在差异:

try{ //a}
catch {//b}
finally {//c}




try{//a}
catch{//b}
//c

编辑:
人们，我知道什么最终会做，我已经使用它很多年了，但是我的问题是在上面的例子中把 //c放进去最终看起来是多余的，不是吗？

12498 次浏览
小开

Finally make sure your code is executed even if you get an exception.

The finally block is useful for cleaning up any resources allocated in the try block as well as running any code that must execute even if there is an exception

http://msdn.microsoft.com/en-us/library/zwc8s4fz(v=vs.80).aspx

小开

Finally block is executed even if an exception thrown in the try block. Therefore, for instance if you opened a stream before, you may want to close that stream either an exception is thrown or not. Finally block is useful for such an issue.

小开
最佳答案

The purpose of a finally block is to ensure that code gets run in three circumstances which would not very cleanly be handled using "catch" blocks alone:

  1. If code within the try block exits via fallthrough or return
  2. If code within a catch block either rethrows the caught exception, or--accidentally or intentionally--ends up throwing a new one.
  3. If the code within the try block encounters an exception for which the try has no catch.

One could copy the finally code before every return or throw, and wrap catch blocks within their own try/catch to allow for the possibility of an accidental exception occurring, but it's far easier to forgo all that and simply use a finally block.

BTW, one thing I wish language designers would include would be an exception argument to the finally block, to deal with the case where one needs to clean up after an exception but still wants it to percolate up the call stack (e.g. one could wrap the code for a constructor in such a construct, and Dispose the object under construction if the constructor was going to exit with an exception).

小开

finally is a syntactic sugar to allow DRY principle in try-catch pattern. Exception is usually thrown if the library code has not enough information to handle some state and wants the client code to solve it. If you don't have library-client code separation, you can handle everything by if instead of try.

Let's see a standard situation without finally:

void myFunction() {
var r = allocateResources();
r.doSomething();
if(somethingBadHappens) {
freeResources(r);
throw new Exception(CODE42);
}
r.doSomethingMore();
freeResources(r);
}

In the snippet above, you repeat freeResources(): this can be multiple statements which you need to repeat. This smells and finally block is the solution for clean code:

void myFunction() {
var r = allocateResources();
try {
r.doSomething();
if(somethingBadHappens) throw new Exception(CODE42);
r.doSomethingMore();
}
finally {
freeResources(r);
}
happyFunction();
}

Let's realize three levels of abstraction:

  • A1 is the library code providing allocateResources() function
  • A2 is our code providing myFunction, consuming A1
  • A3 is some client code consuming myFunction in try-catch block:
function A3code() {
try {
myFunction();
doSomething();
}
catch(Exception e) {
// no hanging resources here
Console.WriteLine(e);
}
}

Now let's see what can happen:

  • if allocateResources() throws in A1, we don't know how to handle it in A2 (A2 code can be run in Console-free environment), so we delagate the situation to A3 without adding any further code. If Exception is thrown here, the finally block is not executed, since finally is bound to try which was not entered.
  • if somethingBadHappens in try block, the stack unwinds to A3 where the situation is handled BUT before it finally block is executed, so we don't need to repeat it if no exceptions happen.
  • before finally we can add catch block and try to resolve some potential exceptions from A1 which may appear in calling r.doSomething methods. Usually we want to handle exceptions as soon as possible to make the client code (A3) more comfortable for client coders.
  • happyFunction() is executed only if nothing throws in myFunction() (inside or outside of try block).

As @supercat points out, the finally block is executed also if try block exits via return. I suggest you avoid this bad habit and have only one return in every function (maybe some early exists at the very beginning of functions). The reasons for single-return functions are:

  1. The code is more readable: you look at the end and see WHAT the function returns. In multiple returns you must find all return occurences, inspect all the ifs, think about when the ifs are satisfied and only then you know what the function returns.
  2. The code can be optimized by compilers, see copy elision.

The reason for multiple returns is avoiding many nested ifs, but there are other techniques to solve it. Exceptions are exception in this rule.

小开

Learn by example

let v = 0;
function f() {
try {
v = 1;
return 2;
} finally {
v = 3;
return 4;
}
v = 5;
return 6;
}


const r = f();
console.log(r, v);

following prints "3, 4"


提交答案