• bvs23bkv33 (unregistered)

    @SuppressComments("frist")

  • MAK (unregistered)

    More like a notorious copy-paste-then-reduce-to-obnoxious-level pattern.

  • someone (unregistered)

    Shouldn't this be a CodeSOD?

  • (nodebb)

    It could try suppressing the message with:

    switch (assetToRemove.getType()) {
			case LIVE:
				asyncJobService.removeAsyncJobsForPresentation(pkg);
				break;
			default:
				// do nothing.
		}
  • Max Chase (google) in reply to Nutster

    "do nothing?" I'm pretty sure you mean "throw an exception or otherwise panic the program with a generic or otherwise unhelpful message that provides no relevant diagnostics". You know, like "Error: this should never happen"

  • RLB (unregistered)

    If there are (enough) other, similar functions in the code where there are cases for other getType()s, I can live with this.

  • Me (unregistered) in reply to Max Chase

    You know, like "Error: this should never happen. Call Bob for help."

    FTFY

  • JM (unregistered)

    If anything in AsyncJobService would expect a specific state related to an Asset in pkg to exist (seems likely), I say remove those AsyncJobs before removing the Asset from the pkg and DB.

    Unless you like the potential for weird, hard to understand error messages that almost never happen, but totally could happen.

  • Jay Mumper (unregistered)

    This reminds me of an old Google "Testing on the Toilet" article that discussed "The Invisible Branch" or the implied "Else" which for a "switch" would be the "default". See that TotT post here: https://testing.googleblog.com/2008/05/tott-invisible-branch.html

  • giammin (unregistered)

    i'm quite sure a modern compiler will replace it with a if

  • markm (unregistered) in reply to giammin

    @giammin: At the machine language level, most switches become a series of ifs. The only other translation is a computed goto, which is efficient only if there are several sequential choices, using all or nearly all of the expected range of values. I would expect a decent compiler to use both methods, or an inefficient compiler to use only ifs, because all switches will translate to ifs and only some could reasonably translate to anything else.

    Are there any languages where the default case must do something? Suppressing the warning instead of adding a do-nothing default seems like the TWTF to me.

  • ZZartin (unregistered)

    /shrug really not a big deal. I've ended up in the same situation where either I was planning on adding more cases that never got added or removed cases for one reason or the other.

    Might bother OCD people reading the code but not a huge deal.

  • Perri Nelson (unregistered)

    "dozens of usages of this pattern"

    Surely that should be "dozens of usages of this anti-pattern."

  • (nodebb)

    Aren't switches supposed to be ON/OFF? :-)

    Addendum 2018-09-18 12:49: Like the ones that turn on (and off) the lights?

  • Lorens (unregistered)

    OK, they have compiler warnings.

    But will the compiler warnings tell them they have one member function named invalidatePresentationCache and another named invalidatePresenationCache?

  • (nodebb) in reply to Perri Nelson

    Is "(anti-)pattern" itself giving it a bit too much credit? Surely this doesn't deserve anything stronger than "anti-idiom".

  • Object delete. (unregistered)

    @SuppressWarnings("incomplete-comment")

  • Object delete. (unregistered) in reply to markm

    Actually not, but the other way around. I still remember the era when compilers were bad at optimization, or didn't optimize at all. This was because of memory constraints. A switch would always result in a jump table. How else would you get one? They are needed for constant-time evaluation guarantee. The programmer was expected to know when this was inefficient, or got an error message like "function too big" on gross misjudgement.

  • Retstun (unregistered) in reply to Nutster

    That won't compile. You need at least an empty statement in the default case:

    default: ;

  • Decius (unregistered) in reply to markm

    At the machine code level, there is only conditional jumps.

  • RLB (unregistered) in reply to ZZartin

    And other OCD people would baulk at having ifs in some places and switches in others. shrug I don't care either way, as long as you're internally consistent.

  • hoodaticus (unregistered)

    I just realized the genius of Java: funnel 80% of the world's BadCode into one language that doesn't compile into shared libraries or executables, runs in a blackbox VM, and therefore cannot contaminate the larger ecosystem. For bonus points, remove the precompiler, operator overloading, pointers, value semantics, and reified generics to make this BadCode

    I just came here because I read the worst code I've ever seen: a distributed cache client that is partitioned by category. It accepts textual queries and determines the category by scanning the query for the first enum Category it finds using query.text().contains(category). Even though it's completely realistic in this environment that the Category list will collide with a field name or value in another cache, meaning the wrong cache gets queried.

    This is further "enhanced" by the fact that the client class is an attempted singleton (they forgot to hide constructor) that uses System.properties to store 1) the specific cache it can connect to (thus making it impossible to access the entire grid in one process) and 2) it stores the correlation ID of the one async message it sends at a time in System properties as well!

    And when we contacted the original dev, he was raving about how awesome and thread safe the code was.

  • Supersonic Tumbleweed (unregistered)

    I guess it's a feature? Writing "case LIVE:" instead of "if (x == GenericEnumType.LIVE)"? Note the enum class qualifier.

  • (nodebb) in reply to herby

    Aren't switches supposed to be ON/OFF? :-) Not necessarily. Think of telephone switches. Or railway switches: https://en.wikipedia.org/wiki/Railroad_switch#Three-way_switch

Leave a comment on “Switch On Suppression”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article