Closed pnodet closed 1 week ago
Maybe this can also be helpful for issues like #525
I think having improvements to signal that you have unhandled / swalled errors in your stack would be awesome.
Are you able to provide examples of how this API would address this problem?
Latest commit: 674840f4fb43a306113d68382286eccbd630b805
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
@supermacro Sorry, rebased this branch with upstream commits and GitHub closed it automatically.
This idea behind this is to leverage the Symbol.dispose new functionality.
const someFunc = () => {
using anExampleResult = aFunctionReturningAResult();
}
for example this would throw an UnhandledResultError
because at the end of someFunc
the anExampleResult
result has not been unwrap or match or another neverthrow result's method
tbh this was more a wild idea that a real proposal bc I see several issues (people forgetting the using
keyword, having error thrown in production…)
I'd be happy to improve this or keep working on it if you or others think it would be a great addition tho!
@m-shaka @dmmulroy what are your thoughts?
Also curious to know @mattpocock if you have thoughts on how to improve this or examples of more complex Symbol.dispose use cases
Don't see how using
differs from just const
here - using
is meant for tidying up a resource when it leaves scope.
With using
we can leverage Symbol.dispose to do something like :
@pnodet Gotcha, that makes sense. Feels possible, but I'm not sure how intuitive the API will feel to most users.
I don't know if it's a use case of using
.
using
can be used to manage "resource" with a specific lifetime. It sounds strongly connected to side-effects, which neverthrow
has nothing to do with
Resource — An object with a specific lifetime, at the end of which either a lifetime-sensitive operation should be performed or a non-garbage-collected reference (such as a file handle, socket, etc.) should be closed or freed.
https://github.com/tc39/proposal-explicit-resource-management
Yeah, this feels like .unsafeUnwrap
with extra steps.
Identifying if a result is used or not should be done statically (prob through a linter) rather than at runtime, no? Closing for now
Typescript 5.2 introduced the
using
keyword. One thing that I find hard with neverthrow is checking for unhandled result. The eslint plugin brings helpful linter errors but I wanted to try implementing [Symbol.dispose] and see if it can help the DX.