How to suppress Java compiler warnings for specifi

2019-01-18 02:41发布

问题:

We are always taught to make sure we use a break in switch statements to avoid fall-through.

The Java compiler warns about these situations to help us not make trivial (but drastic) errors.

I have, however, used case fall-through as a feature (we don't have to get into it here, but it provides a very elegant solution).

However the compiler spits out massive amounts of warnings that may obscure warnings that I need to know about. I know how I can change the compiler to ignore ALL fall-through warnings, but I would like to implement this on a method-by-method basis to avoid missing a place where I did not intend for fall-through to happen.

Any Ideas?

回答1:

If you really, really must do this, and you are sure you are not making a mistake, check out the @SuppressWarnings annotation. I suppose in your case you need

@SuppressWarnings("fallthrough")


回答2:

Is the annotation @SuppressWarnings (javadoc) what you are looking for?

For example:

@SuppressWarnings("unchecked")
public void someMethod(...) {
    ...
}


回答3:

To complete other answer about SuppressWarnings:

@SuppressWarnings("fallthrough")

Try to supress all the fall-through warning at the compiler level is a bad thing: as you've explained, the cases where you need to pass through the warning are clearly identified. Thus, it should be explicitly written in the code (the @SuppressWarnings("fallthrough") annotation with an optionnal comment is welcome). Doing so, you'll still have the fall-through warning if you really forget a break somewhere elese in your code.



回答4:

You could create a structure of 'if' statements in place of the switch. Might not be as visually pleasing however neither is warning supression.



回答5:

@SuppressWarnings("fallthrough")

Java has always followed the C-style of switch statements, where you need to explicititly break out of a switch unless you wish to simply fall through and execute the code in the case below. This can be dangerous of course and errors of this kind can be very hard to track down. In the following example, case 1 lacks a break:

@SuppressWarnings("fallthrough")
public void fallthroughTest(int i)
{
    switch (i)
    {
        case 1:
            // Execute both 1 and 2
        case 2:
            // Execute only 1
    }
}