Hacker News Reader

Comment by Khao | Hacker News Reader

The author is painting a pretty bad picure of C# error handling that isn't close to reality.

In reality, you would never call uint.Parse and let the exception bubble up, you'd call uint.TryParse and handle the logic for failure in the method. There is almost always a way to write your code so it doesn't throw exceptions. I'm working on a pretty large C# codebase for a SaaS website and by doing "find in all files" the keyword "catch" I came up with 174 references. For hundreds of thousands of lines of code, we have had to manually catch and handle exceptions only 174 times.

View on HN

Standard example for exceptions you have to handle: IO. You can't work around it. Want to open a file? That might throw (file doesn't exist/is inaccessible). Want to write? That might throw.

Now, we can argue if you can ignore that, in a controlled environment, and get away with it most of the time.. But that's not what the article is about. He compares exhaustive error handling between the two languages.

imho the author paints a very accurate picture of c#. exception handling remains a mystery to many programmers and is a constant source of errors.

error handling in general is hard to do; to have good, what i would call, "error partitioning"- catching errors/exceptions where they can be fixed is difficult- regardless of exceptions.

perhaps you got your error handling right and don't need more catch clauses, but if I was you I would investigate :)

  public static UInt32 CheckNextVersion([...])
  {
    Contract.Requires(previousVersions != null);
    Contract.Requires(versionString != null);

    UInt32 version;

    if (!UInt32.TryParse(versionString, out version)) throw new ParseException();

    var min = previousVersions.Cast<UInt32?>().Min();

    if (min == 0) throw new NewReleaseImpossibleException();

    if (version >= min) throw new InvalidVersionException();

    return version;
  }

I still wouldn't use this code in production but all the exception handling in the article is completely unnecessary and even throwing those exceptions in the error cases is a design decision. You could as well create your own Result<T> type either containing a value of type T or an error message and return that. Obviously the more support by the language and the compiler you get the better, but you can still do it even without.

  public static Result<UInt32> CheckNextVersion([...])
  {
    Contract.Requires(previousVersions != null);
    Contract.Requires(versionString != null);

    UInt32 version;

    if (!UInt32.TryParse(versionString, out version))
    {
      return Result.Error<UInt32>("Bad version string.");
    }
    else
    {
      var minimumPreviousVersion = previousVersions.Minimum();

      if (minimumPreviousVersion == 0)
      {
        return Result.Error<UInt32>("New release impossible.");
      }
      else if (version >= minimumPreviousVersion) 
      {
        return Result.Error<UInt32>("Invalid version.");
      }
      else
      {
        return Result.Success(version);
      }
  }

Bad programmers write bad code in general, so basing your opinion of C#'s error handling system on their use of it seems unwarranted. Exception handling does not remain a mystery to many programmers, just many bad programmers. Aside from that, the author is a contributor to Rust so I suspect there could be some small amount of bias here.

> ...catching errors/exceptions where they can be fixed is difficult...

What's difficult? When your program is about to do something like say open a file - if you don't want an exception to be raised from that code, you wrap that code in a try...catch. In the catch block, you take corrective action.

The very simple bottom line with error handling in .NET apps is that you handle/log/notify the user at process and thread entry-points like main and AppDomain.UnhandledException. Other than that, you use a try...catch block.

It's a bit of a reach to sling accusations of bias. The Rust project makes it trivial for people to contribute, so anyone with even a passing interest in the language can become a "contributor to Rust" in seconds. If you try and disqualify all of the 1,000+ Rust contributors from writing blog posts about the language, then you most likely also disqualify everyone qualified to write about the language from writing about the language. :P

I didn't sling an accusation, I said "I suspect there could be some small amount of bias". If I were accusing, I would have said "this person is biased.". Despite what you say, I still think the suspicion is valid.

That's fair, although I suspect that your suspicion of bias may be biased due to your usage of C#. :)

The irony here is that people on HN do judge you if you live mostly in the C#/.NET world, but you're arguing against my suspicion of people who contribute to Mozilla.

Do you think it's a far stretch to say that people who actively use open source languages and libraries and contribute to Mozilla projects are much more likely to be biased against anything that Microsoft does?

You're still leaping to conclusions, you're just trying to justify it behind a veneer of persecution. I'm a Rust contributor and I think C# is a fantastic language; it's my dream to tempt Anders Hejlsberg away to Rust. :P I'm also typing this from a Windows 7 netbook, my sole computer, though I'm looking to upgrade to a Surface once Windows 10 is here. We have several former Microsoft employees in our ranks and one of our core contributors is currently interning at Microsoft. It is possible to be critical without there being a hidden agenda!

It is possible, just not probable. You're an outlier.

Error handling is one of the harder aspects of software engineering, IMHO. For starters, those code paths are less tested than others. See this, for example: https://www.usenix.org/system/files/conference/osdi14/osdi14...

uint.Parse vs TryParse misses the point. It's very true that doing proper error handling in C# requires more diligence and attention. I know people like to harp on checked exceptions in java, but if used properly, they at least help with the discoverability aspect.

The fact that you have 174 catch blocks in a very large codebase only reinforces the blog's point, which is you may be missing error handling blocks or you just have very general handlers.

We don't really do catch-all blocks and our app is monitored on New Relic where we almost always have a 0% error rate (rarely we get <1%, most often related to a new commit that we can fix right away)

The only places where we need good exception handling is when doing I/O (network and filesystem). If you have proper layers to handle those things (with queuing/retrying/logging) you end up with a large codebase with very little places where you have to handle exceptions. Anything that is user-input we use TryParse and we do proper validation on the data before doing anything with it. This method is makes it easier to read because you know what the intent is better than doing parse/catch exception in my opinion.

Oh, I agree that TryParse is much better than Parse for cases where parsing is expected to fail. But that doesn't detract from having better error handling capabilities in places where it is needed (e.g. i/o). A lot of the .NET i/o APIs will throw 4-5 different types of exceptions, and as the article states, you need to cross reference docs to see which exceptions are possible on certain calls. It's easy to forget or miss because compiler will not care.

You don't need to know the types of exceptions that are possible on certain calls. All you need to know is what exceptions you can handle. They are not strongly related.

The ones you can handle is a subset of possibly thrown ones, which means you need to know the superset before deciding which ones to handle. You're just describing the handling strategy: pass on it or handle it. It doesn't obviate the need to know what's possible there.

As an example, imagine you're building an application that you know uses sockets. And it's in the requirements that your application must be able recover and re-attempt set of operations. So you look into what kinds of network and socket exceptions exist in your platform, framework, and libraries. From there you decide which ones you should trap and attempt to retry.

At no point do you need to know exactly what methods trigger what exceptions. Yes, you do need to know the superset of all exceptions. But that's no different than knowing the superset of all methods or all classes. My point is, a mapping of methods to exceptions is unnecessary.

Interestingly enough, you might end up handling exceptions which can never be triggered by your application. But this isn't a bad thing, as this can make your application more robust in the face of change.

>As an example, imagine you're building an application that you know uses sockets. And it's in the requirements that your application must be able recover and re-attempt set of operations. So you look into what kinds of network and socket exceptions exist in your platform, framework, and libraries. From there you decide which ones you should trap and attempt to retry.

You need to decide where you're going to handle them, and this depends on how much context is required to handle them appropriately. Sometimes this may require doing it right at the point where the method is invoked that triggers the exception. Even if you decide to not handle the exception, you may still want to know the exceptions so you can rollback/adjust state/invariants before letting the exception continue unwinding.

But where you decide to handle an exception is independent of what methods trigger what exceptions. The decision as to where to put error handling code is based on the program structure and requirements. If my requirement is to rollback the current operation and retry, the error handling goes where that operation starts.

I consider adjusting state based on the exception type poor design. That's very tight coupling. But even so, where you put that code is still independent of where exceptions are thrown. If your data state adjustment requires an exception type, check for that where that state change is appropriate. But what methods trigger what exceptions is still irrelevant.

Reply on news.ycombinator.com