4 ms·
I long wished there was C# Intellisense that showed what kind of exceptions I may receive when calling particular function. At least from code it can infer from
by jve 4y ago
I long wished there was C# Intellisense that showed what kind of exceptions I may receive when calling particular function. At least from code it can infer from:
- .NET library has documentation comments, with <exception> tags
- It could look at my code and see what exceptions get thrown.
- It could be clever enough to know that new might throw OutOfMemoryException
- Clever enough to know checked arithmetic might throw OverflowException
- Might understand where/what exceptions get caught and do not bubble up.
- Smart enough to understand if value can possibly be null and properties are accessed, thus may result in ArgumentNullException.
- As for 3rd party code, I don't know if .pdb provide enough info to know whether particular function call may throw particular exception? But it's all IL, so that should be enough to infer from 3rd party code what kind of exceptions I might encounter:
// throw new ArgumentNullException("serviceProvider");
IL_0013: ldstr "serviceProvider"
IL_0018: newobj instance void [mscorlib]System.ArgumentNullException::.ctor(string)
IL_001d: throw
Eh, what a dream.
- Genbox 4y agoWhat 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.