Let Unchecked.throwChecked return RuntimeException to improve control flow

[leaumar]

AS-IS

class Unchecked {
	public static void throwChecked(Throwable t) {
		SeqUtils.sneakyThrow(t);
	}
}

public Object foo() {
	if (condition) {
		return bar();
	} else {
		Unchecked.throwChecked(new Exception());
		return null;
	}
}

TO-BE

class Unchecked {
	public static <T> T throwChecked(Throwable t) {
		SeqUtils.sneakyThrow(t);
		return null;
	}
}

public Object foo() {
	if (condition) {
		return bar();
	} else {
		return Unchecked.throwChecked(new Exception());
	}
}

Versions:

• jOOλ: 0.9.12
• Java: 1.8.0.91

[leaumar]

Alternative: return RuntimeException instead of T so we can throw Unchecked.throwChecked(ex); instead of return Unchecked.throwChecked(ex), just to shut the compiler up about control flow not ending. Might work better with analysis tools that would complain about a return value being null in context of @Nonnull and such.

[lukaseder]

I can definitely see the problem, and the solution looks clever, but also a bit surprising. I'm not that much of a fan of the return variant. It also only works for reference types, not for primitive types. We could, however, pretend to return a RuntimeException and then you could write something like:

throw Unchecked.unchecked(new TimeoutException());

Will think about this. Of course, in the meantime, the most appropriate workaround is something like this:

public Object foo() {
    if (condition) {
        return bar();
    } else {
        Unchecked.throwChecked(new Exception());
        throw new IllegalStateException();
    }
}

[lukaseder]

There are essentially two options to solving this:

1. Adapt the existing method (incompatibly)
2. Introduce a new method for this purpose

I'm currently favouring the latter, if we can find an appropriate name for it.

[leaumar]

throw Unchecked.throwBack
throw Unchecked.returnThrow/throwReturn
throw Unchecked.feignReturning

fake, false, out, pretend, escalate, reciprocate, echo, mirror, break, elevate, subvert, overcharge, dissent, hide, disguise...

Just throwing some words that come to mind for inspiration

[lukaseder]

Hah, nice ones :). Let's look at it more thoroughly.

1. The method will throw the argument exception. So, terms like "return" won't do the trick.
2. The return value is there only to allow for it to be used in a dummy throw statement. Thus, terms like "reciprocate", "echo", or "mirror" won't do the trick.
3. Since using this new method with a throw statement is the expected usage, repeating the word throw in the method name might be confusing (despite 1.)
4. Terms like "feign" or "fake" might indicate some more complex trickery, or even swallowing exceptions. It would make the programmer feel uneasy about calling the method. That doesn't do it.
5. We're still throwing a checked exception as if it were an unchecked exception, so the term should be somewhat similar to the existing throwChecked()
6. The method can be called standalone without using throw

All of these bullets indicate, if anything at all, that we're about to do a hack :)

[billoneil]

Few more ideas.
throw Unchecked.asUnchecked(new Exception());
throw Unchecked.cast(new Exception());
throw Unchecked.coerce(new Exception());
throw Unchecked.whyCantCheckedExceptionsBeACompilerFlag(new Exception());

[lukaseder]

While I totally agree with the criticism implied in the last name, none of these method names suggesed by @billoneil convey the fact that the method actually throws the argument exception. They all seem to imply that they simply return a transformed exception to be thrown. That's exactly the kind of misleading naming I'd like to avoid.