|
|
|
|
|
|
by pohl
4407 days ago
|
|
|
So you're saying that it's not possible to write reliable and correct code in a language like C#, and not one C# programmer in the world is worthy of being a colleague to the great teacup50. That's the logical conclusion of your assertions, for all of its exceptions are unchecked, and it is otherwise semantically similar. If it's possible to write reliable and correct code in C#, then it's possible to write reliable and correct code in Java minus checked exceptions. As far as APIs are concerned, the important thing is that the API is documented to throw something. It's not at all important that the compiler forces you to pollute either the immediate method's body or its signature and the body of the calling method, etc. |
|
|
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.