As discussed in #137, there are no so many error codes, and depending on the method being executed, the same error code may mean something different.

I'm not in favor of exposing those Categories and ErrorCodes as properties to the consumer as this would compel him to understand the correct meaning of "this error code in that context". I'd prefer exposing concrete Exceptions, deriving from LibGit2SharpException (RepositoryNotFoundException, ...).

My feeling is that if we're not able to infer correct exceptions from the (codes|categories|executionContext) there's zero chance that the consumer will be able to correctly handle those (codes|categories|executionContext) tuples by himself.

Moreover, by exposing our own exceptions, I think we might be more committed to maintain their "contract" (what they mean, when they're thrown) rather than if we just hand out to the consumer what libgit2 just returned.

However, there may be headaches down the road... For instance, when the Klass/Category is Invalid, instead of throwing a derived LibGit2SharpException, should we rather throw an plain ArgumentException?

Even if we do add specific exception types for the variety of class/code combinations, I personally would still like access to the real libgit2 error codes in the actual exception objects. When dealing with exceptional behavior, I've always found that the more you can pull away the abstractions and get to the real information, the better.

If we do go through and add new exception types that derive from LibGit2SharpException I would still want to know the libgit2 error codes/classes and not just in a pre-formatted string. I don't think these two approaches are mutually exclusive.

Why did you stop exposing the GitErrorCode as a strongly typed property? We actually reference that in GHfW. Am I supposed to reach into Data["libgit2.code"] instead? That makes the code uglier and feels more fragile.

Ah, I think in our branch we exposed it as a property. Why would you make this internal and not give me anything else I can use to know exactly what the error is? Parsing exception messages is piss poor and likely to change. Reaching into the Data property is ugly too.

@dahlbyk Sure. As a consumer of the API, I sort of don't care what the backing storage of the properties are. As it stands, I have my own extension methods that do this, but it seems like a no-brainer to have it in the class as part of the API.

But while we're on the topic, it does seem odd to me because Data is read/write, no? So that would allow any code along the stack to modify properties in there. Thus if you created GitErrorCode as a wrapper property, it wouldn't really be readonly, though semantically that's exactly what I'd expect.