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

Dependency on contingency #17

Open
NPCRUS opened this issue May 28, 2024 · 1 comment
Open

Dependency on contingency #17

NPCRUS opened this issue May 28, 2024 · 1 comment
Assignees
Labels
docs Improvements or additions to documentation minor Has only a small impact for the majority of users question Looking for an answer

Comments

@NPCRUS
Copy link
Contributor

NPCRUS commented May 28, 2024

When trying to provide typeclass for sum type(taking into account that split method is implemented, I get following:

[error]  60 |  val typeclass = summon[Default[DefaultTest]]
[error]     |                                              ^
[error]     |No given instance of type contingency.Errant[wisteria.VariantError] was found
[error]     |---------------------------------------------------------------------------
[error]     |Inline stack trace
[error]     |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[error]     |This location contains code that was inlined from wisteria.SumDerivationMethods.scala:126
[error] 126 |        then raise(VariantError[DerivationType](inputLabel))(Unset)(using summonInline[Errant[VariantError]])
[error]     |                                                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I personally already figured it out, but potential adopters, for example people, who only want a replacement for magnolia for their scala3 migration might be set off by this. Would you consider removing this dependency?

@propensive
Copy link
Owner

Everything in Soundness is "safe by default", so you need to explicitly relax the rules to avoid this, but we could find a better way to document this. You have a couple of options:

  • wrap the code in unsafely(...) and let exceptions be thrown
  • wrap the code in safely and get an Optional value in place of the error
  • globally import contingency.errorHandlers.throwUnsafely or .throwSafely (if you're using language.saferExceptions)
  • use tend/remedy, like so:
tend(...).remedy:
  case VariantError(label, sum, variants) => // handle it

The last variant will be checked for error exhaustivity.

None of this is documented yet, and Contingency is not "officially" released yet, but it's one of the most important Soundness modules. I'm part-way through writing a series of blogposts about error handling in Soundness to try to help with understanding this.

@propensive propensive added docs Improvements or additions to documentation question Looking for an answer minor Has only a small impact for the majority of users labels Jun 10, 2024
@propensive propensive self-assigned this Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Improvements or additions to documentation minor Has only a small impact for the majority of users question Looking for an answer
Projects
Status: Todo
Development

No branches or pull requests

2 participants