Long try statements

问题

Is there any drawback to putting most of your code for your function in a try statement. If I do something that requires a try statement, I usually end up doing a lot of work for that function inside the try statement because I usually declare my variables in there and can't use them outside that scope if I do that. Is this common and accepted? Do people usually declare variable before without initializing them so they're not doing everything (including calls to other functions) inside a try statement? Or does it not matter if it's very long?

回答1:

A method should do one thing and do it good. In this case your method is doing two things: business logic and error handling:

public Foo bar() {
    try {
        //business logic that may throw
        //...
        //end even more
    } catch(BuzzException e) {
        //Error handling
    }
}

Very often I find myself extracting the contents of try block into a separate method without error handling:

public Foo bar() {
    try {
        return unsafeBar();
    } catch(BuzzException e) {
        //Error handling
    }
}

public Foo unsafeBar() throws BuzzException {
    //business logic that may throw
    //...
    //end even more
}

回答2:

It matters if it's very long, but not for the reason you think. It matters because it makes your code hard to read and test. You'd better refactor it to several methods:

public void doComplexThing() {
    try {
        SomeObject o1 = doSomethingLessComplex();
        SomeOtherObject o2 = doSomethingElse(o1);
        doFinalThing(o2);
    }
    catch (SomeException e) {
        // handle the exception
    }
}

回答3:

If a try block is getting a little long, it's a good idea to isolate the calls that are actually throwing the exceptions into their own methods. That way you are individually addressing what may be several kinds of exceptions being thrown in that block.

Covering many exceptions in a try with a plain old catch(Exception ex) is going to cause headaches later if you're trying to test or find a "mysterious" bug. This is not to mention things like proper resource/stream handling which is what many checked exceptions are there for.

回答4:

As a senior programmer, I understand the confusion between using a try catch perfectly over the statements that are throwing the exception vs code neatness.

Here I would lean towards try catch over the statements that need it.

First lets understand the need of a try catch. We catch exceptions since we want to handle it right here and right now. If we dont we throw it to the caller. We throw it so that we dont forget to handle it later. Never, Oh!, let me finish this method and then I will worry about the exception handling later. Do it while you code, think, do you need to print a error and return null, or do you need the user to know that something screwed up ? Do you want to consolidate all connection issues to recycle the connection kinda message ? If yes, then throw to your own custom exception. But be sure to handle it. Ignoring and doing bad exception handling is the root cause of increased costs of projects maintenance and customer heart burn. It is the difference between a good product and a sloppy product.

As for code neatness, I have found that comments in catch blocks make it all worth your while. Yes, there will be someone senior to you who will not understand the importance of catching the exact statement, and will catch catch (Exception e) directly. Pathetic, I would say. But you should stick to your ethics when you code. Do it right and do it ONCE.

来源：https://stackoverflow.com/questions/14913854/long-try-statements