3 ms·
What you are asking for is checked exceptions where the caller gets notified by the compiler that the function you call might throw one or more exceptions. How
by Genbox 4y ago
What you are asking for is checked exceptions where the caller gets notified by the compiler that the function you call might throw one or more exceptions.
However, it is worth taking it a step further and focus on "why the error occurred" instead of "an error has occurred".
An example of this is Code Contracts. Like Intellisense, live code analysis with contracts would tell you "the method you call will throw <exception-type> with the input you give".
Not only will that cover giving the user information about which error conditions that can arise, it will also give you the reason why.
- jve 4y agoWell, code contracts are unfortunately dead, not available in .NET Core. C# Anders Hejlsberg, C# designer has a word on checked exceptions for which I agree with him that we should somehow address it more efficiently: https://www.artima.com/articles/the-trouble-with-checked-exceptions https://www.artima.com/articles/the-trouble-with-checked-exc... Looks like what I'd like in the meantime is soft-checked-exceptions. Well, just for documentation purposes. And I'll leave the code for myself. I just want to take into consideration various failure modes and now I can just do generic error handling or waste too much time. Yes, what you are saying, live code analysis would be good enough not to screw up C# language itself with bad design decisions.