Throw checked exception #4288
-
The idea is to let an Exception be marked as checked during throw in a method and thus requiring exception-handling (for that specific type of exception) at call-site of the method. It would look something like- void Method1()
{
throw new Exception();
throw checked(new ArgumentException());
}
void CallSite()
{
// No exception-handling - error
Method1();
// exception-handling for ArgumentException - ok
try { M(); }
catch (ArgumentException e) { throw e; }
// indirect exception-handling for ArgumentException - ok
try { M(); }
catch (Exception e) { throw e; }
// No exception-handling for ArgumentException - error
try { M(); }
catch (ApplicationException e) { throw e; }
} Is there any benefit marking some exception as to be handled at call-site? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 7 replies
-
There are three major problems with checked exceptions, or at least how it is implemented in Java-
For 1 and 2, the solution is not being specific about the Exceptions in the declaration/signature of methods. Joe Duffy suggested only For 3, the language has to "expressionize" exception/error handling. Tried to explore different ways of it for C# in #2734 And we can look at some newer languages like Rust, which has "checked exceptions" of some sort but handles these issues well enough. But the last question is- is this really needed in C#? Isn't C# well enough for now? There were lengthy discussions on exception/error handling in this repo. If there was not some concerns with current state of affairs, there would be no discussion. |
Beta Was this translation helpful? Give feedback.
-
Requiring the exception to be handled at the call-site of the method would strongly encourage developers to write large methods, as you'd be preventing them from slicing off chunks of code into helper methods. Even when I handle exceptions by catching and compensating for their occurrence, I rarely do so in the method directly calling the method that throws. Handling is usually several layers up the call stack. |
Beta Was this translation helpful? Give feedback.
-
Exception are not supposed to be something thrown so routinely that you need a function to effectively declare "i might return a value, or a thrown MyIntegerDataParsingException". Discriminated Unions of Value||Error are probably more appropriate if you want to declare specific error type return values. |
Beta Was this translation helpful? Give feedback.
-
I agree with some of the sentiment here that checked exceptions (i.e. ones where each Exception type is listed in the signature) are better implemented as a special type of return value (bring on discriminated unions!). I do like the idea of being able to distinguish between methods that throw and those that don't, but unfortunately I think that's pretty much impossible to retrofit onto any language, let alone one that's 20 years old! I'm also sympathetic to @theunrepentantgeek 's argument that it may end up being that the vast majority of methods would need to be annotated, vastly reducing its value. |
Beta Was this translation helpful? Give feedback.
-
I no longer support this idea of throwing checked exception. Closing the discussion. |
Beta Was this translation helpful? Give feedback.
I no longer support this idea of throwing checked exception. Closing the discussion.