Hacker News new | past | comments | ask | show | jobs | submit login

> When exceptions are not part of the contract you would have to read the source code of every method you call (and methods they call) to know what exceptions to catch.

Even that won’t help you to find that out when the API takes callbacks or interfaces.

> is to use the root Exception class which everyone agrees is a bad idea

It allows to use lambdas (called delegates but that’s technicalities) and interfaces in APIs. Unlike C++ which allows to throw anything (probably because the standard library with std::exception was too late to the party), in C# the language guarantees that will cover 100% of the exceptions.

The idea is decades old and probably predates exceptions. For example, some pieces of Linux kernel APIs say in the documentation something like “return negative error code if failed”. What you see in almost 100% of use cases of error handling is if( result < 0 ) condition, not a switch-case testing for individual codes or their ranges.

Catching individual exception types is usually a bad idea. Software is incredibly complicated these days; we use tons of APIs and libraries implemented by unrelated people from different continents.

If the language doesn’t make them part of the verifiable contract, you’ll get runtime errors once the implementation changes and a new version starts throwing another exception type.

If the language makes them part of the contract, you’ll be wasting a lot of time making your code compile again after a dependency is updated. This creates an incentive to never update them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: