Reputation: 1624
I have a method which under certain conditions may throw an exception, but most of the time will not. I would like to require anyone who calls this method to catch the exception if they call it under the "dangerous" conditions, but not have to worry about it under "safe" conditions.
public static boolean dangerousSituation; // set somewhere else
public sometimesDangerousMethod() throws MyException {
// some code
// may throw MyException if dangerousSituation == true
// will never throw MyException if dangerousSituation == false
}
otherMethod() {
dangerousSituation = false;
sometimesDangerousMethod(); // shouldn't have to worry about MyException
// if it can't possibly happen
dangerousSituation = true;
try {
sometimesDangerousMethod(); // should be required to handle
// MyException if it may possibly happen
} catch(MyException e) {
// handle MyException
}
}
That is, I would like to require a try/catch block around sometimesDangerousMethod() if and only if dangerousSituation == true.
The reason I want this is because I don't want to bother developers with exception handling if they stick to safe situations anyway. But of course, if a developer does use a dangerous situation, the compiler should let him know.
Is there some way to get this behavior in Java?
I have considered breaking up sometimesDangerousMethod() into two methods: one dangerous, one safe. But I don't think this makes sense since this would require developers to be aware of two methods which do basically the same thing.
Upvotes: 2
Views: 1114
Reputation: 7290
You shouldn't worry so much about the users of your method having to worry about exceptions.
If your method can fail for whatever reason, it should declare the exception (or use an unchecked exception) and throw the exception if it really fails. That's exactly what exceptions are for.
So I think dangerousSituation
is in fact a very dangerous flag. In the code you propose, setting the flag translates to "do not tell me if the method fails [because I know better than the method's implementation that there will not be a failure]".
So, the only reason for not throwing can be a method that will surely succeed. And any decent Java developer should know how to handle exceptions (typically by letting them pass through to a top level where all exceptions are caught and logged).
Upvotes: 0
Reputation: 1052
@mypetlion is accurate on the most part. There are a couple of other options for you to consider is:
Would it be possible to handle the exception inside of sometimesDangerousMethod()
instead of otherMethod()
? If so, then you could pass in the logging/metric object to the method, try/catch
inside of the method, and log an error message or update a metric when this occurs. This way, you don't have to worry about try/catch
in the case that the exception doesn't occur.
You could break it up into 2 methods like @mypetlion mentioned and with a bit of organization, it may be good enough code:
`
public class Solution {
public static boolean dangerousSituation; // set somewhere else
public void notDangerousMethod(){
// will never throw MyException
}
public void dangerousMethod() throws MyException {
// throws MyException
}
public void sometimesDangerousMethod() throws MyException {
if(dangerousSituation){
dangerousMethod();
} else {
notDangerousMethod();
}
}
public void otherMethod() {
dangerousSituation = false;
// Option 1:
if(dangerousSituation){
try{
dangerousMethod();
} catch(MyException e) {
// handle MyException
}
} else {
notDangerousMethod();
}
// Option 2:
try {
sometimesDangerousMethod(); // should be required to handle
// MyException if it may possibly happen
} catch(MyException e) {
// handle MyException
}
}
`
Depending on contents of sometimesDangerousMethod(), this may be overkill. If it is a few very simple lines of logic, it might be worth it to implement your original design. I don't think the developers would mind :)
Upvotes: 2
Reputation: 17455
You're missing the point of the word Exception. Your code should not throw an Exception
unless there is an exceptional situation. Properly designed code that consumes your code still needs to handle the possibility of an exceptional situation.
Upvotes: 0
Reputation: 2524
The functionality you're looking for doesn't exist. You can either split it into two methods, or your coworkers will have to use a try-catch. Sorry, but sometimes the answer is just "No".
Upvotes: 2