Good point. I have used Call Hierarchy, although when I read your comment, the idea that popped into my mind was “debugging”. 
I use “Find references in workspace (<ctrl><shift>g)” a lot while refactoring (particularly while deleting code), but not Call Hierarchy. I’m not sure why; I’ll investigate that feeling next time I’m doing something like this.

Also, yes, the point of this is to leverage the compiler to help make sure we’ve removed all traces of the original null. I hate null checks within code I control, as that is indicative of a bad citizen (see Good Citizen)

Just a little contribution: Many ideas do have a way to search for references hierarchically. I now for sure that in Eclipse is called “call hierarchy”, but I am quite sure that on Idea is possible too, but I do not know the shortcuts 🙂

Still, the “it won’t compile”  technic does prevent you from missing any case.

Good point. Although I would hope (for my sanity) that if there are catch everything blocks in the code, that they’re doing something sensible and I don’t need to go and change them at this point.
(I’ll probably go and rip them out at the soonest opportunity though 🙂 )

Yes, although the advantage of this method is that it propagates _beyond the direct usages_.

The advantage is that it highlights the direct and indirect usages of someMethod. Direct usages is obviously trivial, it’s the indirect usages where the bugs usually lie.

If my someMethod() from above was used in another method like so:
public Result someOtherMethod() {
  if (someValue) {return something;}
  return someMethod();
}

then the value of someOtherMethod can also be null. So I also need to check the callers of that method, and so on, until I reach someone who either knows what the sensible thing to do with the value is or, I reach the extremities of the program (for example, the main loop or the request handler).

In the simple case, there isn’t a need to do this, but removing a null return should encompass the entire system, and this method ensures that this is the case.

You are correct about reflective calls, but I would hope that people using reflective calls were aware of the power (and therefore, danger) of that approach. 

Hmm, I do not understand the second part of the explanation. The first five markers is all you need I would think. The rest is noise – although I do not understand why/how out of five usage places you would get another 20. If I have a method cal chain like so:
someUsageOfUsage -> usage -> npeProblem(this is the method where we add new Exception)I would only get trouble reports with the last portion of the chain (5 usages) pointing to the usage methods. The rest is noise, but I think compiler would not even complain aout the first link in the chain) and I woud not like to deal with that at all. So, I do not really see transitive use here. How?

Of course, it would be worth mentioning that the limitation of the trick is the loose coupling (reflective calls, JSP pages, etc). This method fails, and would only give the person using it a false sense of understanding.