Gah.. I sort of feel dirty

[FnordMan]

triple nested try/catch block in the .net app I maintain.

something like this:

Try
      <dial phone>
Catch
      Try 
           Try
                <disconnect> (this guy doesn't have it's own error handling code
            Catch
            End Try
            <disconnect method 2>
            <dial phone>
      Catch
             <throw "error" here> (any errors get ate and presented, this is an app that basically can't fail)
      End Try
End Try

 

[aL Mac]

Do they throw different types of exceptions by chance? If so you can just have multiple catch blocks one for each type. You may be able to combine 2-3 this way.

You can also refactor your code and make it call a function which has the try/catch in it to reduce nesting. But it isn't necessarily terrible to have 2-3 nested try blocks.

Also make sure some of your code shouldn't actually be in a finally block (cleaning up, disconnecting etc)

 

[FnordMan]

Unfortunately I couldn't use a finally block.
I thought about putting disconnect #1 in it's own function but was too lazy.
The whole thing just kind of bugs me somewhat. I know it isn't bad but it's just one of those things.

 

[aL Mac]

To me it looks like you should refactor that into separate methods. Disconnect() etc.. in fact your psuedo-code / comments is basically sorta how you need create your methods.

Too lazy? I mean I'm VERY lazy.. but all you do is highlight the code, right click -> refactor extract method.. Type in a new name and hit enter.

 

[FnordMan]

To me it looks like you should refactor that into separate methods. Disconnect() etc.. in fact your psuedo-code / comments is basically sorta how you need create your methods.

Too lazy? I mean I'm VERY lazy.. but all you do is highlight the code, right click -> refactor extract method.. Type in a new name and hit enter.

Where does that come from? I don't see that here in Visual Studio 2010.

 

[mikeblas]

Not sure why this is noteworthy. Note that catches in inner trys might throw to the outer catches. If "dial phone" throws, for example, the next outer catch will work the exception.

 

[FnordMan]

Not sure why this is noteworthy. Note that catches in inner trys might throw to the outer catches. If "dial phone" throws, for example, the next outer catch will work the exception.

It's more noteworthy in the fact that it shouldn't even be necessary. Try/catch blocks slow things down. In a properly done environment the dial phone function (beyond my control) should just return true/false to indicate if it succeeded or not. Same with the disconnect functions.

 

[Dogs]

It's more noteworthy in the fact that it shouldn't even be necessary. Try/catch blocks slow things down. In a properly done environment the dial phone function (beyond my control) should just return true/false to indicate if it succeeded or not. Same with the disconnect functions.

Compared with the amount of time it takes to actually dial a call and get a response with most systems out there, the overhead of even several try-catch blocks will be fairly small.

Thus, I find it extremely unlikely that any application involving dialing a phone system would be so performance sensitive that you wouldn't be able to afford proper error handling. In the real world, the value of having your application handle failures in a way which meets the business need will greatly offset any performance gains which could be had by forgoing error handling altogether. The exception chain allows you to give much more insightful information about the reason behind the failure. Keeping track of why the failure happened is likely going to be more important than performance.

 

[mikeblas]

It's more noteworthy in the fact that it shouldn't even be necessary. Try/catch blocks slow things down. In a properly done environment the dial phone function (beyond my control) should just return true/false to indicate if it succeeded or not. Same with the disconnect functions.

You can process a few dozen million try/catch blocks in the time it takes to dial a 7 digit phone number, even with an automated dialer. When your dial function returns "False", what are you going to tell the user? "Call failed?" Trading a few cycles for a richer application seems smart.