Why is this better than throwing errors or using Promise.resolve()?
I know it is inefficient because creating a new error with a stack trace each time is bad for performance. However, you can also throw errors which do not extend Error to avoid this. Destructuring the output and explicitly checking for errors every time seems to be quite the hassle.
Re:Problems with TypeScript
by JamesSwift on Wednesday January 15, 2020 @05:01PM
(#22059240)
Because the error/success is encoded in the type, you are forced to handle the error case. If you aren't also wrapping throwable functions in `try/catch` then you have a lot of unhandled error cases.
If you know that something truly isn't going to error then you can just force cast it as `foo as Success<T>`. That will still blow up at runtime if its not a `Success`.
Alternatively, you could introduce a monadic chaining that is able to pipe `Result<T>` objects through many functions then handle at the end.
Re:Problems with TypeScript
by threatofrain on Wednesday January 15, 2020 @02:44PM
(#22057704)
Seems quite like Go.
Here's a small example:
```
function fetchCurrentWeather(){ return fetch(...) .catch(() => ({ error: new NetworkError(), value: null}) .then(res => res.json()) .then(maybeWeather => Weather.is(maybeWeather) ? { value: maybeWeather, error: null} : { error: new DecodeError(), value: null}) .catch(() => ({ error: new DecodeError(), value: null})) }
// And then you use it somewhere in you react app
async initialFetch(){ try { if (this.state.isLoading) return; this.setState({ isLoading: true, weather: null, error: null }); this.setState({ weather: await fetchCurrentWeather().then(reault => { if (result.error) throw result.error; return result.value; }) }); } catch (error) { this.setState({ error }) } finally { this.setState({ isLoading: false }); } }
render(){ return ( <div> {this.state.isLoading && ...} {this.state.weather && ...} {this.state.error && ...} </div> ) }
```