change tryGet()
API misuse to Defect
#41
Open
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.
Assuming a
Result[T, E]
withE: Exception
,tryGet
has the nasty side effect of triggering{.raises: [E, ResultError[void]].}
. This is because it tries to play nice whentryGet()
is called on aResult
that has not yet been initialized.That is not in line with how Nim typically operates. Accessing items that are not initialized may yield to SIGSEGV in many situations.
tryGet()
semantics are well-defined for an initializedResult
.Calling
tryGet()
on un-initialized data is not a typical usecase and could instead become aResultDefect
. This way, it is not required anymore toexcept + discard
theResultError[void]
for hypothetical API misuse, or to alternatively pollute the callstack with{.raises.}
.The alternatiev would be to
raise E(msg: ...)
instead, but that one may trigger unexpected behaviour as it hides the API misuse error.