Making Akkurate usable with Either exception handling

[PoisonedYouth]

Because in most of the new projects I'm starting the exception handling is done using an Either type I directly checked if it integrates in the usage of Akkurate. Akkurate already returns a result type consist of Success and Failure that needs to be mapped to the corresponding left and right type of an Either

private fun <T> ValidationResult<T>.toEither(): EitherNel<Failure, T> =
    when (this) {
        is ValidationResult.Success<T> -> Either.Right(this.value)
        is ValidationResult.Failure -> {
            Either.Left(this.violations.map { Failure.ValidationFailure(it.message) }.toNonEmptyList())
        }
    }

private fun <A> Iterable<A>.toNonEmptyList(): NonEmptyList<A> =
    NonEmptyList(first(), drop(1)) // Because we are sure the violations are not empty

The toNonEmptyList function is working because an Failure at minimum contains one violation. So this can be translated to a list of failures (ValidationFailure is a class of a failure hierarchy).

[PoisonedYouth]

It will be good to introduce the possibility to stop the evaluation process after the first failure occurs so that it integrates with usage of Either without NonEmptyList like:

private fun <T> ValidationResult<T>.toEither(): Either<Failure, T> =
    when (this) {
        is ValidationResult.Success<T> -> Either.Right(this.value)
        is ValidationResult.Failure -> {
            Either.Left(Failure.ValidationFailure(this.violation.message ))
        }
    }

[nesk]

Stopping after the first violation is something planned as a configuration option.

I will add everything to the roadmap soon.

[dave08]

Would there also be a possibility to bind() a ValidationResult to an existing either { } block?

[PoisonedYouth]

I think this is only possible by extending the Akkurate library, there need to be an own Validator type for this. Because this class is a sealed one it is not possible to use an own implementation in my code.

[dave08]

That's the idea, there's supposed to be an Arrow extension planned... but meanwhile, why not make your own wrapper that returns an either? Instead of using the library's Validator block and then converting the result all over your code?

It might be nice to know what could be planned to make it easy to migrate to the library's Arrow support later, though...

[PoisonedYouth]

I will try a wrapper approach and give feedback.

[dave08]

And it might be nice to have a first class validator type for Either, like there is for suspend functions? But then it might be hard to keep Arrow out of the dependencies of the main module...

[PoisonedYouth]

I think a better approach is to provide the possibility to extend the current API by one that can integrate with Either not adding it as part of the library "core" because this will bind it to a special other library.

[dave08]

Yeah, the truth is, it probably can't extend the existing sealed class anyways, since the result type is different, unless the library would use generics for the return type, which might complicate thing considerably...

[nesk]

As already told, Arrow is clearly on Akkurate's roadmap (will try to clean it and make it public tomorrow).

Like you've already done, keep posting if you have any suggestions for this specific integration, I will add them to the roadmap. 😉

[nesk]

@PoisonedYouth @dave08 The public roadmap is available!

[PoisonedYouth]

If you are interested in support, let me know

[nesk]

Akkurate now provides support for Arrow: https://akkurate.dev/docs/arrow-integration.html