[teacup50]

No, I'm saying it's not possible to write reliable and correct code in C# using exceptions without also doing all the heavy lifting of the compiler. You can also write reliable and correct code in dynamically typed languages, which involves doing even more work on behalf of the compiler.

This is not unique to C#; if you review coding standards for C++, you'll see plenty of people who have adopted a no-exceptions approach, Google included. Simply put, exceptions are a failed experiment, because checked exceptions are the only mechanism by which the type of your methods is fully defined.

As far as API documentation, that something gets thrown is part of the return signature, and it's no more pollution than expressing the return type is.

Your willingness to employ ambiguity as a means to avoid having to do the work necessary to fully specify your system's behavior is a lazy and logically flawed position; it creates a cognitive load for all consumers of your APIs, and breaks the utility of the compiler that we rely on to write and maintain reliable software more easily.

[pohl]

Excuse me, but what exactly is it that you think you know about how I write code?

[teacup50]

You rely on human validation of your code's return type values via unchecked exceptions, and don't understand why your code is resultantly ambiguously defined.

[pohl]

LOL...If you're just here to argue against your own imagination I guess you don't need me here.

[teacup50]

If you're ignorant to the degree that you don't understand how exceptions are part of the function's return type, it has nothing to do with my imagination.

[pohl]

It's only the imaginary me in your head that doesn't understand that.