Question: Handling errors with custom sub-types

[aloslider]

I'm trying to get into the idea of new way of handling exceptions and errors with the "Error" system and got some questions:

1. I'm not familiar with creating own system of the error codes at all, so it may be a silly question: why error code is not optional for error sub-types? Managing codes is a bit hard as I need to remember its values or check it every time in the file. I tried to solve it with enums, but not only it made me write a lot of repetative code - I can't use enums as integers without explicit casting, so I'm out of ideas.
2. From №1: there are @catch functions that match specific exception type, but not for custom Expected or Exceptional errors like this:

@catch(e => e is MyError, (MyError e) => ...)

Is it possible to match sub-errors by type? Or I miss some clarification on how to deal with custom errors on wiki or in other discussions? I understand that you catch base-type errors (e.g. static readonly Error UserExited = Error.New(100, "user exited")) by its static instance, but for custom errors I can only match on its text or code, as my error instance being created dynamically, e.g. in a guard:

from _ in guard<Error>(n > 0, new MyError(n))
| @catch(codeOrText, ...)

3. From №2:
   I need to explicitly specify generic type (or explicitly cast as (Error)new MyError(n)) for guard to make it work with my custom Expected type (as it can't cast custom error to its base Error type for some reason), otherwise it's apparently trying to use this overload. Did I messed up something or it's intended?

[louthy]

The reason why the codes are useful is exactly because of the matching. The codes will be compared when doing a match. This allows for localisation of text and parameterised errors (where the content of the message changes) , or sharing of codes, etc. It's also very fast.

You can use 0 as the code if you like, then the Message is compared - so if you have unique error-messages it will work fine with subtypes. But I'd encourage you to leverage the codes.

Also, you only need sub-typed errors if you're going to be carrying extra data, otherwise I'd encourage you to use the Error.New(...) variants to create errors (again leveraging the code as a discriminator rather than the type).

What I tend to do is create an Errors type that contains all the errors in the app/library, i.e.:

    public static class Errors
    {
         public static readonly Error UsernameRequired = Error.New(101, "username required");
         public static readonly Error PasswordRequired = Error.New(100, "password required");
         public static Error ErrWithInfo(string info) => Error.New(102, "An error occurred: {info}");
         public static Error ErrWithData<A>(A value) => new MyErrorType<A>(value);
    }

This keeps all error codes in one place, allows for pre-allocating the error type for constant errors, and it makes pattern matching relatively easy, because you can do things like this:

    @catch(Errors.UsernameRequired, ...)

From №1: there are @catch functions that match specific exception type, but not for custom Expected or Exceptional errors like this:

Yep, that's a bit of an oversight, so in v4.4.5 that I've just released you now have:

    // Catches all Expected errors
    @expected(e => ...);           

    // Catches all Exceptional errors
    @exceptional(e => ...);           

    // Works with any sub-type of Error
    @catchOf((YourErrorType e) => ...);   

    // Works with any sub-type of Exceptional
    @exceptionalOf((YourErrorType e) => ...);   

    // Works with any sub-type of Expected
    @expectedOf((YourErrorType e) => ...);   

The last two aren't needed really, as they can be achieved with catchOf, but they're more declarative, so useful for talking to readers of your code.

for custom errors I can only match on its text or code, as my error instance being created dynamically, e.g. in a guard

Obviously with the new functions you could work with the new types if you're declaring; but yes, that's a limitation. The simplification of errors to not need to declare a 100 different Exception classes has some trade-offs, namely that for parametric errors it's more efficient to match on the code than to generate a new instance of an error just for matching.