[zvrba]

> is a tricky situation: would it be really handled incorrectly?

Depends. You can't know in a situation like

    try {
        DoA(); DoB();
    }
    catch (SomethingEx e) { ... }

If previously only DoB could throw SomethingEx and now DoA() can also throw it, the handler is almost certainly incorrect handling if this is some "generic" exception. C#/.NET base library is notorious for using InvalidOperationException for all kinds of unrelated crap.

> It's trivial (but tedious) to write code like this

Eh. Methods without "throws" would be "unchecked" at runtime as well. So my (imagined) best practice would be that non-private methods declare their exceptions and leave it to the caller whether and how to wrap them.

> And in before "don't catch and wrap Exception!"

Oh, I do that all the time for precisely the reasons you mentioned. Exceptions from the lowest level are most precise and least useful as there's no information about the context. (Unless you go down the unmaintainable rabbit hole of parsing the call stack.)

[Joker_vD]

So, if I understand your proposal correctly, you want to split the current 2-pronged approach "catch everything, handle what you can, re-throw what you can't wrapped in FooException" into a 3-pronged one: "catch what you believe can be handled by you or your users, handle what you can, re-throw what you can't wrapped in FooException, and the system will re-throw everything else wrapped in UnexpectedException". The difference is that if now some dependency of Foo would change drastically, the Foo's users won't be able to accidentally swallow or even see the new exceptions, those will go all the way up as UnexpectedExceptions and will draw the due attention.

[zvrba]

> So, if I understand your proposal correctly,

You understand it correctly.

> if now some dependency of Foo would change drastically

The most frequent "drastic change" being writing new code and fixing bugs. It's extremely easy to widen the set of exceptions thrown by a method and zero tooling to help you with finding out what exceptions can be thrown from the code.

Say what you want about Java, but its division of throwables into errors and exceptions makes sense. Errors like stack overflow, VM faults, etc., should not be exceptions. Under this scheme, they would always propagate out of the method unwrapped. Again, .NETs predefined exception types are botched beyond repair.