(earlier)

Suppose we're trying to null-mark this existing code without changing it:

try {
  ...
} catch (SomeException e) {
  e = expressionThatDoesNotExcludeNull();
}

The answer might be one of:

1. e's type here is nullness-applicable
   • Therefore we expect a finding here, but a change to @Nullable SomeException makes it go away
2. e's type here is nullness-inapplicable for reason of being intrinsically non-null
   • Therefore we expect a finding here, and suppression is the only way out
3. e's type here is nullness-inapplicable for reason of being (morally) a local variable root type
   • Therefore we expect no finding here
4. This is deep enough into implementation code that we really don't care
5. other?

Notice that the difference between 2 and 3 is just whether we think of e more like a parameter or more like a variable.

I'm not sure that this 1-5 choice even affects which issues a flow-sensitive analyzer could find and report. If so, is there any big reason to have a finding at the site of the assignment anyway?