To violate soundness, you'd need to get into a situation where an unexpected checked exception leads an expression or variable to end up with a value of some ty

To violate soundness, you'd need to get into a situation where an unexpected checked exception leads an expression or variable to end up with a value of some type that doesn't match the expression or variable's static type. This would be easy if the hole worked in the other direction where an exception should be thrown but isn't. Because then you could probably do something like confuse the definite assignment analysis in a constructor body to make it think all fields are initialized by the end of the constructor, like: class C { final int x; C(bool b) { if (b) { thingThatMustThrow(); } else { x = 1; } } } Here, if the control flow analysis expected that `thingThatMustThrow()` will always throw an exception, then it might conclude that all paths that reach the end of the constructor body will definitely initialize `x`. But if that method doesn't throw an exception, then execution could proceed merrily along and `x` never get initialized. (In practice, this isn't an issue because field definite initialization analysis is already unsound so the VM default initializes every field anyway.) But in this case, it goes in the other direction. You have code that isn't expected to throw that does. I can't think of a situation where that would lead Java to end up with a value of the wrong type flowing somewhere unexpected.