And this is exactly my question. I believe it can’t be done in a straightforward way and even if going non-straightforward, all known potential solutions are either very limited, unreliable or require huge amount of processing power. This problem is not fully solvable as for now. Even if it would be, we don’t always have the whole codebase at the compile time.
And I don’t think it has anything to do with lambdas. We talk about compile-time analysis and type erasure happens only at runtime. The main problem are virtual calls. We don’t know what we call, so we don’t know what it may throw. Of course, we can limit the tool to direct calls only, but that would provide very unreliable results and would create a false sense of safety.
look we just wanted some syntax sugar that would help us manage unchecked exceptions at the API contract level.
if API throws X when it encounters Y and a caller may want to catch X, it shouldn’t (accidentally) throw X when it encounters an unrelated Z or it’ll be silently swallowed, making an undebuggable mess.