Java: How to propagate a "method exit" when tucking-in exceptions?

• By "method exit" - I mean the actions in a method such as return or throw new... that the compiler considers the end of a method - if you could please tell me the accepted word for "method exit", I will edit the question

My problem is the following:

• I do a lot of throw new RuntimeException(...

• So, I decided to "tuck it in" as:
  public static void quickRaise (String msg) { throw new RuntimeException(msg); } <BR>

  And then I can reuse it.<BR>
  (This will help me in the future to enhance the procedure around raising Runtime Exceptions and even
  switch to a custom Exception class, without fishing in the code for exception throws)

• However, where before I could write:

    public MyType doSomething() {
  try {
  //...
  return new MyType (parameter);
  } catch (Exception e) {
  throw new RuntimeException("msg")
  }
  }
  

  And the compiler would correctly understand that "this method either exits by return or by throw" and therefore there are no logical "dead ends"

When I changed throw new RuntimeException("msg") to quickRaise("msg"), the compiler no longer considers my method "complete". It complains about a missing return statement, even though quickRaise is semantically equivalent to throw (or at least this is what I am trying to do!)

Let me try to reiterate the problem by a reproductive example (this will not compile, which is the problem):

public static void main(String[] args) {
System.out.println(doSomething());
}
public static String doSomething () {
try {
//... Some fun stuff going on here
return "Something";
} catch (Exception e) {
quickRaise("Could not find handshakes");
//throw new RuntimeException("If you uncomment this line, it will compile!");
}
}
public static void quickRaise (String msg) {
throw new RuntimeException(msg);
}

Your idea is highly inadvisable.

For example, this is just bad codestyle:

try {
someIO();
} catch (IOException e) {
throw new RuntimeException("Problem with IO");
}

The reason it's bad is that you have now obliterated the actual information about the problem. That information is locked into 5 separate parts of that exception you just caught: Its type (for example, FileNotFoundException, its message (e.g. "Directory /foo/bar does not exist"), its stack trace, its causal chain, and as throwables are objects, any particular extra detail for that particular kind of exception (such as the DB-engine-specific error coding for some SQLException).

Throwing this info away is silly.

All you'd need to do to fix this, is to add the cause:

} catch (IOException e) {
throw new RuntimeException("IO problem", e);
}

Now the IOException is marked as the cause of the exception you are throwing, which means in error logs you'll see it + the message + the stack trace of it + the stack trace of any causes it had as well.

All you need to do to make the compiler realize that the method ends here, is to throw it:

public static RuntimeException quickRaise(String msg) {
throw new RuntimeException(msg);
return null; // doesn't matter, we never get here
}
// to use:
throw quickRaise(msg);

But, as I explained before, this is a very bad idea.

Secondarily, having the idea of 'I just want to throw an exception and maybe later I want to replace the kind of exception I throw' also doesn't really work out: You need to pick a proper exception for the situation, therefore you cannot write a one-size-fits-all throw method in the first place.

Okay, so what do I do?

Primarily, learn to embrace throws clauses. If your method fundamentally does I/O (for example, the javadoc of it and/or the name makes that obvious, it is for example saveGame(Path p), or scanUserHome), then it should be declared to throws IOException.

If your method is an entrypoint (as in, it is the first point where your own code begins running), then your method should be declared to throws Exception. For example, your public static void main() method should throws Exception. Sometimes an entrypoint isn't main but something else (a webhandler routing hook for example), and sometimes backwards silly franeworks prevent you from doing that, but there tends to be a wrap functionality (such as } catch (Exception e) { throw new ServletException(e); }).

For exceptions which are both [A] fundamentally not part of the method's purpose, but more part of an implementation detail and [B] is very unlikely to go wrong and there's not much you can do other than hard crash if it would, then, yeah, rewrap as RuntimeException. There isn't a lot of point in ever changing this 'globally' for all such exceptions. At best you belatedly realize that failure is a bit more likely than you originally thought and either create a proper exception for it and document this behaviour. But that's, again, on a per-method basis, not something you can apply in blanket fashion.

Your approach is fundamentally at odds with the need for the compiler to see that the flow terminates at the throw statement.

I'd suggest having a utility method that just constructs an exception, which you then throw from the original point.

It's either than or put dummy returns after each call to quickRaise().