Normally, I'd do this:
try
{
code
开发者_JAVA技巧 code that might throw an anticipated exception you want to handle
code
code that might throw an anticipated exception you want to handle
code
}
catch
{
}
Are there any benefits to doing it this way?
code
try
{
code that might throw an anticipated exception you want to handle
}
catch
{
}
code
try
{
code that might throw an anticipated exception you want to handle
}
catch
{
}
code
Update:
I originally asked this question w/reference to C#, but as A. Levy commented, it could apply to any exception handling language, so I made the tags reflect that.
It depends. If you want to provide special handling for specific errors then use multiple catch blocks:
try
{
// code that throws an exception
// this line won't execute
}
catch (StackOverflowException ex)
{
// special handling for StackOverflowException
}
catch (Exception ex)
{
// all others
}
If, however, the intent is to handle an exception and continue executing, place the code in separate try-catch blocks:
try
{
// code that throws an exception
}
catch (Exception ex)
{
// handle
}
try
{
// this code will execute unless the previous catch block
// throws an exception (re-throw or new exception)
}
catch (Exception ex)
{
// handle
}
If I could choose the second I would probably separate this into two functions.
Neither, just use multiple catch blocks for specific exceptions (unless there is just a ton of code in the block and only a couple of lines may throw an exception.In that case I would go with the second method).
You're thinking about this the wrong way. What do you need to do in your catch blocks? If you would recover from any of the possible exceptions by running the same code, no matter which operation threw the exception, then use one catch block. If you need to do different clean-up operations depending on which operation threw, then use multiple catch blocks.
Also, if you can use try/finally or the RAII pattern instead of try/catch, then you should.
Second method is better in my opinion because it allows you to trap errors with more accuracy.
Also wrapping your entire code inside one big try/catch block is bad, if your app has some sort of problem and it crashes but since you trapped a big generic execption the chance that you can actualy handle it correctly is lower.
You should have spesfic parts inside try catch, like if your reading a file or taking user input. That way you can better handle that exeception
There are time we want to show specific error to user.
try{
try{
... send message
}
catch(exception e){
...log error
...rethrow send related error/show custom error
}
try{
...try to receive response
}
catch(exception e){
...show receive related error
}
//finally close the connection
}finally{
...close connection
}
I prefer the second method - it makes debugging easier, error handling more accurate and also feeds nicely into your unit testing nicely too.
I would go for the 2nd option, but whenever I see this code pattern my first feeling is to think about splitting it into multiple functions/methods. Obviously whether to do so depends on what the code is doing ;)
It depends on the nature of the type of errors happen in your code.
If the handling of those errors you are going to do is same go for single try ... catch for that group of code. Else it will be too tedious.
If the errors required different handling, separate it because you have to.
DO NOT APPLY A SINGLE METHOD FOR ALL CASES. PROGRAMMING MOST OF THE TIME IS CONTEXT SPECIFIC :)
You need to reach a balance of "GOOD/COMPLEX" and "BAD/SIMPLE". The more you code, you will be less stuck in this kind of dilemma :)
Happy programming!
Second method. Keeping the code that might throw an exception separate from other code - keeps the section smaller and easier to manage instead of wrapping all code, even that which will not throw exceptions.
2nd way but ideally use code guards - try/catch can be costly, if you catch an exception.
精彩评论