Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: de-result unexpected errors #368

Merged
merged 47 commits into from
Jul 5, 2024
Merged

refactor: de-result unexpected errors #368

merged 47 commits into from
Jul 5, 2024

Conversation

ComradeVanti
Copy link
Collaborator

Currently most functions in the project use Result based return types. When I started to implement this I was of the opinion that all functions should use the Result based workflow to allow for railway oriented programming.

In the course of refactoring this project to use Results I sometimes had a feeling that maybe some types of errors are not suitable to be used in Results. Recently I read this blog post which confirmed my suspicions and enhanced my understanding of error handling.

In this PR I revert my over-zealous usage of Results. They should now only be used for handle-able domain errors.

@ComradeVanti
Copy link
Collaborator Author

The PR also adds a few more error messages, so that is what I will merge it as

@ComradeVanti ComradeVanti marked this pull request as ready for review July 5, 2024 08:10
@ComradeVanti ComradeVanti merged commit 44ba315 into master Jul 5, 2024
6 checks passed
@ComradeVanti ComradeVanti deleted the domain-results branch July 5, 2024 08:10
github-actions bot pushed a commit that referenced this pull request Jul 5, 2024
# [3.3.0](3.2.0...3.3.0) (2024-07-05)

### Features

* add more error messages ([#368](#368)) ([44ba315](44ba315))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant