Try and handling (specific) typed exceptions

[NickDarvey]

I'm wrapping a library which throws on expected errors.

private EitherAsync<AccessFailure, AuthenticationResult> TryGetAccessToken (IAccount account) =>
  TryAsync(_pca.AcquireTokenSilent(_scopes, account).ExecuteAsync())
    .Map(Either<AccessFailure, AuthenticationResult>.Right)
    .IfFail()
    .With<MsalUiRequiredException>(_ => Left(AccessFailure.AccessDenied))
    .OtherwiseReThrow()
    .ToAsync();

Is there a way to avoid the explicit types in .Map(Either<AccessFailure, AuthenticationResult>.Right)?
(If I just use Right method from prelude then it returns an EitherRight to which my Left is not convertible.)

Otherwise, I'm sure this is a common pattern (going from Trys to Eithers), so is there a better way to approach it altogether? (I had a look in the tests but didn't examples which match on specific exception types.)

[louthy]

There’s two natural-transformation extension methods called ToEither:

One maps to Either<Exception, A>, the other allows you to map the Excepton

[NickDarvey]

RE: mapping the exception, is that just a matter of:

TryAsync(etc)
  .ToEither(e =>
    e is MyFirstException => MyFirstError ?
    : e is MySecondException => MySecondError ?
    : ExceptionDispatchInfo.Capture(e).Throw())

or is there a way of getting an ExceptionMatch helper here too?

Also the TryAsync variant wraps it in an Common.Error. So,

1. are the Try and TryAsync supposed to be symmetric?
2. how does one match on the type of exception inside the Error?
   (I feel like I ought to have a ExpectedException here but I can't see any examples of constructing one or using one.)

[NickDarvey]

Hah, I just saw

language-ext/LanguageExt.Core/Monads/Alternative Value Monads/Try/README.md

Lines 4 to 5 in 4371712

	**NOTE: These monads have been superseded by the `Eff` and `Aff` monads in the language-ext _Effects System_. They will continue
	to be supported, but no new functionality added**

Looks like I need to relearn! I've been away far too long.

I'm guessing this @catch thing is something like what I'm looking for.

Are there examples of catching things thrown by the uhhh implementation(?) of a runtime? For example, what's the idiomatic way to catch an (expected, not really exceptional) IOException thrown if a file is locked when invoking WriteAllLines?

[louthy]

The 'big idea' (for want of a better phrase) is to get everyone using Error. Error has been upgraded to support exceptional, expected, and many-errors. This allows a bit more fidelity when defining errors.

You can pre-build your errors, i..e:

public static class YourErrors
{
    public static readonly Error UserNotFound = (123, "User not found");
    public static readonly Error InvalidPath = (124, "Invalid path");
    public static readonly Error UnauthorisedAccess = (125, "File locked: unauthorised access");    
    ...
}

You can then use those to 'pattern-match' against with @catch. So, that allows you to define the set of errors for your application, concretely, in one place and then use those readonly fields as a strongly-typed set of errors (easy to find usage-of, easy to rename, easy to change the error-message, easy to localise, ...).

When it comes to exceptional errors and the Aff and Eff wrappers around existing exception-throwing code, you should look to catch exceptional errors in the implementation, as soon as possible, and convert to something more appropriate. Jumping away from the built-in exceptions really is a question of pragmatism: it will take effort to map all existing exceptions to well-defined errors for your domain, you could argue that it's unnecessary overhead. The alternative view is that by explicitly catching and mapping all exceptional errors, you take control over the expected and the exceptional.

Anyway, you can then wrap up File.WriteLines like so:

public static Eff<Unit> WriteAllLines(string path, Seq<string> lines) =>
    Eff(() =>
    {
        System.IO.File.WriteAllLines(path, lines);
        return unit;
    })
    | @catch(ex => ex is UnauthorizedAccessException, YourErrors.UnauthorisedAccess)
    | @catch(ex => ex is PathTooLongException,        YourErrors.InvalidPath)
    | @catch(ex => ex is ArgumentNullException,       YourErrors.InvalidPath)
    | @catch(ex => ex is ArgumentException,           YourErrors.InvalidPath)
    | @catch(ex => ex is NotSupportedException,       YourErrors.InvalidPath);

[NickDarvey]

you should look to catch exceptional errors in the implementation, as soon as possible, and convert to something more appropriate. Jumping away from the built-in exceptions really is a question of pragmatism: it will take effort to map all existing exceptions to well-defined errors for your domain, you could argue that it's unnecessary overhead. The alternative view is that by explicitly catching and mapping all exceptional errors, you take control over the expected and the exceptional.

That's exactly what I'm trying to do :) you don't need to convince me there.

you can then wrap up File.WriteLines like so

Great example. Thanks!

As part of "catching exceptional errors in the implementation, as soon as possible", shouldn't traits like Sys.Traits.FileIO define these Error-inheriting error types and force the implementation to return them? That is, making the System.IO ('Live') implementation of the FileIO trait capture the exceptions thrown by System.IO and return one of YourErrors like in your example?

The 'big idea' (for want of a better phrase) is to get everyone using Error. Error has been upgraded to support exceptional, expected, and many-errors.

Also, just a design question, if csharp supported discriminated unions would you let users define their own error types? Or would you continue to promote this Error type to avoid the proliferation of a TError type argument everywhere or other reasons?
(I get why it exists right now, I think, but I see a cognitive burden for myself when it comes time to handle each error where I'm needing to consider what possible Error.Codes I have to care about, ensuring exhaustiveness, etc.)