51–60 of 72 posts
Spent sometime to complete the document of my rust Result like library `unwrapit` for JS/TS. Still think this might be a proper way to deal with errors in JS/TS
This is interesting. Does it have any performance impact?
https://github.com/musicq/unwrapit/blob/d5c437a235ad1f5ad042...
I've come to the conclusion that such a library offers little benefit in languages which embrace exceptions. You have to basically wrap everything , making the code hard to read, and without proper ADTs and pattern matching it's easy to forget handling all cases. There's also no way to prevent ppl from falling back to exceptions, so now you have a mess of exception and result handling. And bc there is no blessed way,…
In my opinion, it never tries to prevent people from handling exceptions using try/catch, instead, it enrichs the error handling solutions.
`wrap` function is just a simple way for users to adopt this Result type quickly. I think in projects, developers should create their own Result usually, can check this example.
https://musicq.gitbook.io/unwrapit/recipe/return-result-with...
Why make it complicated? The language supports catching errors, use that. You may not like it but that's the thing you have. Of course you can wrap errors, return [response,error] or whatever in your implementation of api calls etc. but you don't need third-party libraries for that.
So this provides a way that told you the function you called might throw. It's more like an alert before a crash.
[res, err] is good, actually I used this style for a long time. `unwrapit` is a nicer way to let you write [res, err], like type hints and other utility methods.
Will throw this in here as it's been useful for errors if operating with try/catch
I'd prefer an api like this: const [result, error] = attempt(() => someFunc()); This way you don't have to wrap all your functions.
That seems a lot more ergonomic. I can already see someone copy-pasting `wrap(myFunction)(args)` everywhere :-)
https://musicq.gitbook.io/unwrapit/recipe/return-result-with...
For anyone who has NOT written in rust yet, there's nothing in the readme that explains what's intuitive or easy about the library. It doesn't even explain what to expect as the `status` getting logged, not go mention other possible values.
Earlier quoted context omitted.
Agree with that. Exceptions suck, try-catch is an infamy, and errors not in the signatures or exploitable in any way by Typescript is a living nightmare. But what I hate even more is multiple ways to handle errors.
You sound like, living in a car society is a nightmare because you can't dodge cars that run into you. Hopefully there's an ideal world for you.
More like living in a society with invisible cars. You only know there was a car when it hits you. And every time you move a foot you have to first try to throw a pebble to check if there's a car
Earlier quoted context omitted.
From memory: even if the arguments in favor were thoroughly convincing, it’s basically an insurmountable task to produce the types to cover even common runtimes, let alone the vast ecosystem of libraries (often themselves with community-maintained types). The failure mode for poor coverage of error types is worse than the failure mode of untyped errors, for instance because it would tend to influence where developers…
Maybe I am misreading you but for example, in Swift, marking a function as “throws” makes it a compiler error to not handle the error, and makes it an error to not throw an error or return in the function. In Typescript, the error in a catch handler is of type unknown. I don’t see how it could be any worse than basically untyped errors AND unpredictable runtime errors without reading the docs or implementation. At le…
function libFoo(foo: string): throws FooError;
function libBar(bar: number): boolean;
The argument as I understand it, which is convincing, is that types like this are inevitable if typed errors were to be introduced. The scope of even well typed code with no documentation of even the errors thrown directly is enormous. The scope of code which might propagate errors from calls deeper in its stack is unimaginable. And there is basically no way to do static analysis to meaningfully reduce that space.
It could be fair to say this was a missed opportunity earlier in TypeScript’s development. But introducing typed errors retroactively would lead, trivially, to millions of cases like the above. Many in very hard to find ways.
Could those types be produced and refined to be as high quality as existing types (first party or community provided)? Of course. But it would take years. And unlike introducing types where none exist, the gradual story just doesn’t exist. You’d have to treat literally every function and property access as `throws any` to get safety equivalent to the gradual types story for non-errors.
And the incentive to type one’s own code with errors is hard to imagine: how can I, as a library author, say with any confidence what anything I write throws, if I have no idea what the underlying code throws (or if it really even does)? Why would I take on the maintenance burden of getting it wrong? Or incomplete? Or incomplete and wrong?
Is there a reason that typescript doesn’t/can’t add throwing function annotation syntax?
Just use a library that already contains this and more functional programming idioms, like fp-ts or its successor, Effect [0]. It is a little more complex to learn but much more robust that simply implementing your own Result and other types. [0] https://www.effect.website/
Effect looks great. Strangely enough, I recall dreaming of it and recoiling at how much of a good idea it is -- can't wait to give it a proper go in a project.
"recoiling" implies a negative response, ie revulsion or fear