[Question]: Why not use Result everywhere?
See original GitHub issue@stemmlerjs hope you are well!
I would like to know why in repos you have chosen to try catch and throw Errors.
Yet in most other places you are returning a Result.fail
or Result.ok
.
Thanks!
Issue Analytics
- State:
- Created a year ago
- Comments:5 (1 by maintainers)
Top Results From Across the Web
Ask HN: Why do search functions everywhere not return what I ...
It's driving me nuts. All over the web, search functions don't actually return the word you searched for. They seem to all do...
Read more >c# - Await on a completed task same as task.Result?
Parallel task code can use Result and Wait . Note that (1) is by far the common case, hence my tendency to use...
Read more >Avoiding simple mistakes in async await - Anthony Steele
Use await not .Result to get the result of a task. Avoid becoming synchronous again wherever possible. Avoid Task.Run . Avoid async void...
Read more >Long Story Short: Async/Await Best Practices in .NET - Medium
The only time we truly want to await is when we do something with the result of the async task in the continuation...
Read more >988 Frequently Asked Questions - SAMHSA
FAQs About 988 Basics · What is 988? · Is 988 available for substance use crisis? · Does the 1-800-273-8255 number still work?...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Because repo implementation is using library that is created by others.
When-to-throw-errors-purposefully B: When we encounter errors that we don’t expect or know how to deal with. These are errors that really mess up what we were trying to do and can be caused by an infinite possibility of things that we didn’t expect or assume would happen:
I think you definitely can implement it with
Result
class. Don’t see any problem with it. Instead of {succeeded:boolean} you will have Result.ok/fail(), from what I learned from his blog, I think this one you have choice to choose between simple json and Result class.