Discussion: shortcomings of exception handling and failure reporting in C#

[orthoxerox]

Lately there've been several proposals about simplifying try-catch statements:

• shorter try/catch statements #1015
• [Proposal/Discussion] Catch/Exception Patterns #989
• Yet another try expression proposal #980
• Proposal: Per statement exception handling support (trycatch) #965
• Proposal: Exception preview operator #787
• try/catch expression #786
• Allow singleline expressions in try-catch blocks #616
• Proposal: Add syntax support for returning a default value from a method if an exception is thrown #464

Rather than concentrating on discussing concrete solutions, I want to discuss the problems we're trying to solve. Feel free to comment on what you find annoying about exception handling in C#.

try/catch is very wordy when you're handling individual throwing statements

This is especially annoying when you use Allman style braces, you get six lines of noise per call:

try
{
    DangerousCall();
}
catch
{
    HandleFailure();
}

try/catch is exceptionally wordy when you want a fallback value out of a throwing expression

Similar to TryX methods before out var, this is one of the places where you cannot use var:

Foo foo;
try
{
    foo = DangerousGetFoo();
}
catch
{
    foo = _someDefaultFoo;
}

throwing is the only standard way to signal failure other than TryX

There's no expression-friendly way to signal failure that will be understood by the consumers of your library. If failure is normal and expected, you can use TryX pattern, but even with out var it will interrupt the control flow.

If failure is abnormal, but still possible, you're expected to throw an exception, which will have to be caught and handled by the consumer of your library. You might hate catching exceptions in your code when using external libraries, but you're forced to throw them as the library writer.

---

Do you have anything else to add?

[Logerfo]

I'm also annoyed by the "verbosity" of simple try/catch blocks, which even made me write the following:

public static Boolean Try(params Action[] p)
{
   foreach (Action a in p)
      try
      {
         a();
      }
      catch
      {
         return false;
      }

   return true;
}

There is no need to tell me this is a bad practice, I'm pretty aware of that.

What I read most when talking about making parenthesis optional is that it can be ambiguous because there can be multiple catch clauses and also an finally clause. For example:

try
   M();
catch
   try
      N();
   catch
      C();
   finally
      A();

Can also be read as

try
   M();
catch
   try
      N();
   catch
      C();
finally
      A();

Questions raised: would the compiler force you to use parenthesis or assume something? That ambiguity is bad.

One thing I could think of is also making the try keyword optional. The finally and catch statements would refer to the last block of code. For example:

M();
N();
catch A();

equals

M();
try
{
   N();
}
catch
{
   A();
}

and

{
   M();
   N();
}
catch
   A();

equals

try
{
   M();
   N();
}
catch
   A();

This one is tricky:

M();
catch
   N();
finally
   C();

Equals

try
{
   M();
}
catch
{
   try
   {
      N();
   }
   finally
   {
      C();
   }
}

To make the finally block refer to the first try block, the following would need to be done:

{
   M();
   catch
      N();
}
finally
   C();

That would let my first example to be written like this:

M();
catch
   N();
   catch
      C();
   finally
      A();

Which actually would be compiled as:

try
{
   M();
}
catch
{
   try
   {
      N();
   }
   catch
   {
      try
      {
         C();
      }
      finally
      {
         A();
      }
   }
}

That approach is even shorter and less ambiguous if you realize the simplicity of the rule. If it's a better approach or not is not for me to judge, I'm just sharing my thoughts. I hope we can find a way to make our lives easier while coding, without making it harder for other people. Best regards!

[HaloFour]

@Logerfo

I think that this looks pretty good. Could eliminate a few more newlines as well for faster code.

public static Boolean Try(params Action[] p)
{
   foreach (Action a in p)
      try { a(); }
      catch { return false; }

   return true;
}

[iam3yal]

@HaloFour I think more than anything people get annoyed by the braces but for these simple cases the match expression should cover this given that it's going to support exception handling to an extent.

[HaloFour]

@eyalsk

Indeed, but my point is that even today when the braces are required they don't force you to layout your code in such a manner. Allman, K&R, etc., they're just guidelines. I don't find it to be a sin to elect a different indentation, or even none at all, where it would benefit the legibility of the code. Simple try/catch statements like that can already be rendered to form more succinct than even match expressions are likely to achieve.

Thank IPU that C# is not a whitespace sensitive language and take advantage of that fact.

[bondsbw]

@HaloFour The most compelling need to me is an expression form.

var t1 = T() catch C();
var t2 = T() catch (IOException ex) C(ex);

There may need to be limits (e.g. one catch only). Verbosity isn't the main problem here, so a more verbose expression form would be fine too... though I wouldn't go out of my way to just make it harder to read.

[gulshan]

Quoting myself from #989

Regarding exception handling in general, I think pre-condition failures should not be exceptions and should have separate way of handling. That may be a Result type. Or the compiler can ensure the preconditions are met at the call-site, just like it currently does for the types and will be doing for the nulls in future. Exceptions should only be thrown when an error occurred during the execution/computation of an statement/expression. And languages should not make it easy to "swallow-all-the-exceptions". At least swallow-all can have a explicit different syntax like panic when it is needed (top-level handlers). But it is probably too late for .net ecosystem to embrace that or any new error-handling philosophy.

Another thing I shall add, nested try blocks looks very complex and kind of enforces indentation. Then to make code simpler, we consolidate multiple try blocks into one with all the catches together.

[Logerfo]

@HaloFour several people uses auto format features like resharper, which will ignore any "out of the box indentation"

[HaloFour]

@Logerfo

Sounds like a bug that should be fixed with Resharper. Visual Studio is perfectly happy to leave braces and statements on a single line.

[Logerfo]

@HaloFour it's not a bug, it's a feature! 😄
"Every piece of code should be formatted as the selected rule". It helps, for example, accepting pull requests with different code style and easily make it homogeneous with yours.

[DavidArno]

@bondsbw,

@HaloFour The most compelling need to me is an expression form.

I think @HaloFour's proposal of "catch patterns" would cover that:

var t2 = switch (T())
(
    case var t: t,
    catch (IOException ex) : C(ex);
);

[DavidArno]

How about new syntax, that avoids backward compatibility issues and avoids nesting to allow blocks to not be used:

try catch
    M();
catch
    N();
catch
    C();
finally
    A();

The rules behind it being:

1. try cannot be used inside a try catch block/statement. Thus avoids the ambiguity issue.
2. If an exception occurs, control drops through to the first matching catch. If an exception occurs in that. control drops again to the next matching catch and so on, or is thrown up the stack if there's no match. finally is executed as normal.

This could also be provided in expression form:

var x = try catch (
    M(),
    catch (SomeException e when e.Foo) N(),
    catch (SomeException e) C()
);

[iam3yal]

@DavidArno I don't think that try catch makes a lot of sense but more importantly it's confusing and the first rule will probably make people wonder why it's not possible.

[bondsbw]

@DavidArno The switch is a workaround, and not a very nice one.

[DavidArno]

@eyalsk,

I think you are right. Re-reading it, it looks like M() belongs to the first catch. Back to the drawing board... 😀

[HaloFour]

@Logerfo

it's not a bug, it's a feature!

I really dislike the concept of suggesting that the language should change its grammar in order to satisfy the OCD of third-party tools (or developers).

I'm surprised that R# is so strict about this. I've not used it much in Visual Studio because frankly I think it renders Visual Studio nearly unusable from a performance standpoint, but I've done a bit of Java in IntelliJ and that editor would even go so far to reformat the appearance of code (not the actual code) within the editor to collapse small definitions into a single line because it frankly reads a lot better that way.

@DavidArno

try cannot be used inside a try catch block/statement. Thus avoids the ambiguity issue.

How do you propose the syntax rules for that? What would follow try catch that would include any other statement(s) but exclude try? Sounds like you'd have to redesign half of the specification to make that parseable.

If an exception occurs, control drops through to the first matching catch. If an exception occurs in that. control drops again to the next matching catch and so on, or is thrown up the stack if there's no match. finally is executed as normal.

That sounds like a big departure from how exception handling works in any language I've seen. Why should statements in the catch blocks be implicitly caught also?

[HaloFour]

@bondsbw

The switch is a workaround, and not a very nice one.

Why is that a workaround? switch expressions are coming to the language and will be the appropriate way to write branch-based expressions that are more complicated than would be reasonable with nested conditional ternary expressions. Allowing them to also handle exceptions via normal pattern matching seems like it would handle the expression scenarios just fine. Sure, it's a little more verbose than a syntax that would encourage exception swallowing, but that is very intentional.

F# exception handling is syntactically similar, although F# separates if via try expressions, e.g.:

let t2 = try
    T()
with
    | :? System.DivideByZeroException => C(ex)

F# does separate try expressions from match expressions though. If C# were to follow that same path then maybe the following syntax might work:

var t2 = try (T()) (
    case Exception ex: C(ex)
);

But then you'd have to nest try and switch expressions which might get a bit nasty.

[bondsbw]

@HaloFour I like the switch/catch proposal. But like the classic switch, I wouldn't prefer it for simple expressions with only one catch.

FWIW I think switch fits better for multiple catch clauses (akin to often being a good fit for multiple conditional branches).

[DavidArno]

@HaloFour,

How do you propose the syntax rules for that? What would follow try catch that would include any other statement(s) but exclude try? Sounds like you'd have to redesign half of the specification to make that parseable.

Not sure it would be half. I haven't looked at the spec to be sure. As other rules exist around which statements can appear at a given point, eg with expression bodies, then it may not be a big job. Or it could be huge. I was just throwing a radically different idea at the wall to see if it would stick.

That sounds like a big departure from how exception handling works in any language I've seen.

Sounds like a good reason to me: C# can be first with something! 😉

Why should statements in the catch blocks be implicitly caught also?

They'd be implicitly caught as the lowering would involve adding a try to each catch block, with the following catch clauses being replicated each time another implicit try is added through the set of catches.

It's an idea for radically reducing the syntax of nested try/catches, so obviously it's very different to how the existing stuff works.

[iam3yal]

@DavidArno

Sounds like a good reason to me: C# can be first with something!

async/await? 😄

[gulshan]

@orthoxerox In the second case, type inference is often lost, which is another point.
@HaloFour

But then you'd have to nest try and switch expressions which might get a bit nasty.

As I have said, I like the separation of try and switch/match expressions. I don't think we "have to" nest. A nested expression can easily be separated into two cleaner expressions.

[benaadams]

Can currently exception filter or pattern match (and squidge lines together)

Filtering

public int Test2()
{
    try { return Method(); }
    catch (DivideByZeroException) { return 0; }
    catch (IOException e) when (e.Message == "Nah") { return 2; }
    catch (IOException e) { throw new InvalidOperationException(e.Message, e); }
    catch (InvalidOperationException) { return 3; }
}

Pattern matching

public int Test()
{
    try { return Method(); }
    catch (Exception ex) {
        switch (ex) {
            case DivideByZeroException e: return 0;
            case IOException e when e.Message == "Nah": return 2;
            case IOException e: throw new InvalidOperationException(e.Message, e);
            case InvalidOperationException e: return 3;
            default: throw;
        }
    }
}

[DavidArno]

@eyalsk,

async/await?

That was "inspired" by F#'s asynchronous workflows... 😀

[iam3yal]

@DavidArno Well, yes but still async/await doesn't exist in F# the way it exists in C#, it's more convoluted and it was C# that pushed other languages toward this model of async programming such as JavaScript, Python and not sure where it stands in C++ but anyway my point is C# definitely made this pair well known. 😉