Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Automatically catch and wrap exceptions thrown in @effect.result functions?
See original GitHub issueIssue Description
Currently, it looks like any non-Expression exceptions thrown in a effect.result decorated function is re-raised by the decorator. I’m wondering if it might be useful to have the decorator return an Error object instead, wrapping the raised Exception object?
This would reduce the amount of manual conversions from raised exceptions to Error objects, enabling easier interfacing with code/libraries that throw exceptions.
Thoughts? Happy to take a stab at implementing this. Either way, I’m digging this library!
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@mlw214 I noticed you referenced python/typing#193 on variadic generics in this thread. Heads up that we’ve been working on a draft of a PEP for this in PEP 646. If this is something you still care about, take a read and let us know any feedback in this thread in typing-sig. Thanks!
This is great! Thanks for your corrections/input.
One thing I noticed is that the decorator doesn’t appear to work well with the
@currieddecorator. Personally, I’d like to get them to play nicely together, if possible. I’ll play around with@catchto see if I can make that happen. Regardless, I hope to have a PR for you this weekend.