问题
I have a try-catch block that I wish to break like a switch block but I couldn't find a recommended way of doing it. I'm fetching a lot of data in the try-catch block and wish to stop the fetching in between in case a certain condition is met. Just to get it working for now, I've deliberately forced the code to go into the catch block:
int i=0;
try {
//--do stuff----
if(//-------is condition met?--------//)
i = 1/0; // divide 1 by 0 -- a definite exception
}
catch (Exception e) {//---------do nothing---------//}
Is it safe to do this or should I go for another way?
EDIT:I'm fetching some xml data(actually, a lot). Depending on the internet connection, I need to stop the parsing after sometime(time-out) rather than go through the entire stream. I go through loops but I also make some calculations later. It doesn't make any sense to calculate with incomplete data, so I would prefer to just skip the whole thing.
回答1:
Either break or throw will do what you want (and the throw would be preferable, you at least have some traceability as to WTH you're doing.
[edit]
what: try {
System.out.println ("before break");
break what;
} catch (Exception e) {}
}
[/edit]
回答2:
This code smells of some anti-pattern but without more context we can't prescribe a better design. In general, you should only throw an exception for a truly exceptional condition in the state of your program. You should especially not throw an exception for normal (expected) control flow, instead you should use control flow statements such as loops (using break/continue) and return.
If you do wish to keep this structure (even though you should not) then I suggest explicitly throwing a special exception class to make it clear what you are doing, e.g.:
public static class ConditionMetException extends Exception { }
// ...
try {
// do stuff
if ( /* Is condition met? */ ) {
throw new ConditionMetException();
}
} catch (ConditionMetException cme) { /* Do nothing. */ }
But again, you're likely better off refactoring to use a loop and the built in break command.
回答3:
Throwing an Exception just to break is bad practice.
Would this work for your situation?
- Put the code currently inside the try into another method, fetchLotsOfData(). It can still throw IOException or whatever is appropriate.
- When you want to stop doing your thing fetching the data, just return. Perhaps returning some true/false or status for the success.
So your final code is something like
int recordsRead = -1; // -1 means failure
try {
recordsRead = fetchLotsOfData();
}
catch (IOException ioe) {
// handle the exception
}
// process what you got...
回答4:
I'm going to answer the "is is a good idea?" part of the question: No.
It is not a good idea to use exceptions to implement expected flow-of-control. It is possible, but not expected, just as it's possible to make all your variables Strings and implement all your data structures in arrays.
Try-blocks are for creating a scope boundary that has certain guarantees at termination (the catch and finally behavior). A code maintainer seeing:
try{ ... }catch(Exception x){}
would very strongly tend to either rethrow x (perhaps wrapped) or eliminate the block entirely.
Try-blocks are not about what's inside their scope. That's what standard looping constructs and, better, functions are for. Your question simply goes away if you put your scope in a function:
RetVal doStuff(Arg arg){
//--do stuff----
if(//-------is condition met?--------//)
return myResult;
}
回答5:
It is not the try-catch that you should worry about breaking out of. From what I can tell, you are looking to do something along the lines of:
try
{
// do thing 1
// do thing 2
if (!done)
{
// do thing 3
// do thing 4
if (still not done)
{
// do thing 5
}
}
} catch (Exception e)
{
}
If that is what you are trying to do, then that is probably how you should do it (instead of trying to escape from the try-catch). The other way is to shrink your try-catch blocks to surround each task individually.
If you provide more context to your question then it may be possible to provide a better answer.
回答6:
Just put the rest of the fetching into an if block with the inverse condition:
//--do stuff----
if (!shouldStop) {
// continue doing stuff
}
回答7:
Looking by your code
int i=0;
try {
//--do stuff----
if(//-------is condition met?--------//)
i = 1/0; // divide 1 by 0 -- a definite exception
}
catch (Exception e) {//---------do nothing---------//}
if the condition is not met? then you dont need to worry about using break, and
if the condition is met, there will be definitely an exception, and it is handled in catch(although you are not doing anything)
回答8:
If there is no other way you can use a block label
load:{
if(test)//skip the remaining load block
break load;
}
Otherwise you could refactor the loading code into a different method and return early.
回答9:
Do not use exceptions for non-exception error handling. This is likely a named anti-pattern. If so, I don't know the name.
Here is an example of breaking out of a loop when an exception is thrown and not using exception handling to perform non-exception error handling:
try
{
while (... whatever ...)
{
... do something that might throw a BlammoException.
}
}
catch (BlammoException exception)
{
... handle the exception.
}
回答10:
Just throw whichever exception you want caught...
boolean stopLoop = false;
while (!stopLoop) {
try {
int key = Integer.parseInt(userInput);
if (key > cutOff) throw new NumberFormatException();//<--like this
else {
System.out.println("Good job, your number didn't suck");
//do some stuff...
stopLoop = true;//<--End loop after some stuff
//some more stuff, or..
if(nomorestuff)break;//<--exit loop
}
catch (NumberFormatException nfe){
System.err.println("Enter a number less than "+cutOff);
}
}//end while
来源：https://stackoverflow.com/questions/8762630/what-is-the-best-way-to-force-a-try-block-to-break-in-between