Custom result type with typed errors #999
Merged
+134
−65
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Improvement/adjustment over stdlib Result<T>, by providing a way to strongly type the error. This has the upside of making handling the errors easier (no need to pattern match against the type of a generic Throwable). Additionally, enforcing knowing your error conditions might reduce the possibilities of making bad decisions in life. However, Kotlin does not support type unions in any meaningful way. This makes implementing something akin to a 'flatMap' (fold/map which merges failures produced by the transform function) very difficult. This was not previously an issue, as everything was just a generic Throwable, thus easily convertible, and as error handling required pattern matching the type via when-expressions anyway. With strong error types, nesting result expressions becomes a bit cumbersome. This can be somewhat alleviated with .fold trickery for our current use-cases, but might become an issue in more complex cases. I explored a number of possible approaches with variations of using when-exporessions, fold, flatmap-like functions, etc. and this current iteration is the best I could do. I hope most of the shortcomings of this approach can be eliminated with well thought utility functions for any common pain-points that pop up.
Handling the errors without '.fold's makes things a bit more straightforward, albeit a bit more verbose. For overall readability and simplicity, this is good.
Kailari
force-pushed
the
refact/custom-typed-result
branch
from
1403b97 to
0bcd50f
Compare
|
Yksinkertaistin hieman oppijanumerohaun virheitä. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Melko pitkälle viety Proof-of-Concept
Result-tyypistä vahvasti tyypitetyillä virheillä.Toteutettuna
TypedResult<Value, Error>-tyyppi ja sille joitain yleisimmin tarvittuja toimintoja. Toteutus muistuttaa rajapinnaltaan vahvasti standardikirjastonResult-tyyppiä, sillä erotuksella, ettäSuccess- jaFailure-variaatiot on toteutettu aliluokkina ja itseTypedResultonsealed class. Tämä mahdollistaa mm. exhaustivewhen-lauseetSuccessjaFailure-luokkia käyttäen. Tämän hyödyllisyys on tosin melko rajallista (ja/tai johtaa verboosiin koodiin), sillä Kotlin ei mahdollista mm. destrukturointiawhenlauseiden osana, joskin utility-metodien ja itseTypedResult-luokan toteutus oli tämän ansiosta melko helppoa.Olennaisimpina muutoksina:
as Error.Validation-tyyliset tyyppimuunnokset putoavat pois.flatMap-kikkailua vartenErrorluokalle piti lisätäError.Oppija-aliluokka, kaikkiatoOppija/getOppijanumero-putkesta syntyviä virheitä vartenJälkimmäinen muutos on lähinnä sen demonstrointia varten, että tällainen on ylipäätään mahdollista. Tämä on lähimmäs tyyppi-unioneja (esim.
OppijaValidationFailure | OppijanumeroException) mitä Kotlinin rajoitteiden puitteissa sain aikaiseksi.