This might fix error handling in JS

Agree on #2. Neverthrow and similar libs have made life far easier imho. I’m all for anything that makes it easier reason about code.

How about this syntax: const [error, result] = try await unsafeFn();

I have been doing this in Scala with a union and pattern matching to bubble up errors instead of using exceptions.

errors as values is a practice that should've been implemented in coding languages from the start

or just use the Either type

When i use upload things with nest.js it didn't work it out ?

Interesting that you went ahead and used Effect.ts with UploadThing. Didn’t know that.

Ive said it before and Ill say it again, kotlin getting rid of checked exceptions nullifies their nullification checking, trading one mysterious source of error for another rather than leaving checked exceptions and having both solved and aiding editor tools in alerting you about possible exceptions.

The proposal sucks, keep trying

The clunky cluttered error handling is the whole reason I don't want to continue learning golang

I like the way Axios handles this with their isAxiosError(err) function, think more libraries could benefit from something similar. I think most people end up writing a handleError(err) function which deals with all the various ways an error can be thrown don't they 😅

Also, put on a lint rule in your app so you can't throw strings, you'll thank me later

I see the same arguments against Effect as I did for TypeScript (complexity, learning curve, etc). At work, we got on the Angular 2 bandwagon quite early, so was forced into TS. Absolutely no one would have predicted the wide adoption TS got when Angular started using it.

I'm posting this for posterity.

I’m probably just dumb but I write lots of code where I return a generic Error rather than throw, and “enforce” callers to handle it by expressing that at the type layer. I could see some carefully thought out variation on this becoming a conventional pattern. But again I am dumb, and work in a 13 year old monolithic codebase where there are countless reinventions of wheels running amok.

then use := that come from the same language

The biggest problem with this proposal is that there is no forced usage in JavaScript, like Go, and just ignoring it is valid to the language. So, this would be a breaking change to have proper support for a feature like this. I don’t see how it would be possible to add the ability to fail a script for a future usage of variables and constants.

What I usually do is handle errors in interceptors and return null as response if any error occurs. Works well when you have very well error handling on the backend but otherwise it sucks. The safe await thing theo mentioned is awesome and I feel shit why didn't I think of this before 😂

What if javascript added a safeTry method to promises, so you could do the following?
const [error, response] = await promise.safeTry();
This would not require any syntax change.

Would love a JS tips page from Theo he discusses in these videos. It's hard to bookmark and revisit code in videos. Probably I will make such a page.

My man is thinking of go in js

There is something terribly wrong with trying to mimic exception handling as a Result pattern.

bruh.
const tryPromise = async (promise) => {
try {
const value = await promise;

return [null, value];
} catch (error) {
return [error, null];
}
};

const [error, response] = await tryPromise(fetch("any-url"));

This feels like a "nobody uses it because of our poor support so we won't improve the support on it either" 🤷🏼‍♂️

"Nobody is using mass transportation so let's only build roads."

It's amazing the JS garbage collector leaves anything behind. 😉

finalllly been waiting for this for years, only if we knew what functions will actually throw errors tho

So this proposal is just silly because you can already write this functionality directly in vanilla JS without a language extension. There are even multiple ways to implement it. People have forgotten how to program.

Effect seems very similar to neverthrow after you showed it - but it's less demaning in terms of how much you need to write with it to get benefits

I strongly discourage to abuse this "Micro" library and rethrow error by wrapping the original one if you are doing server side JS. Every try catch comes with a slight but istantiating a new Error is a massive hit, a function that will throws new errors 10% of the times will perform between 2 to 5 times slower then no errors.

The tuple syntax of Go doesn't work well in JS because once err has been defined in the function you cannot easily reassign it because in theory you should always do something like:

let [res1, err] = ...
let [res2, err] = ...

but this will not work because err is already defined so you need to do something like err1, err2 or avoid destructuring.

My suggestion is just to leverage union types:

function foo() {
if (ok) return res
else return new BadResult("Something went wrong") // This is a custom class
}

const res = foo()
if (res instanceof BadResult) {
// error handling here
}

// ok status

Go mentioned!

Just use Golang man\\!\!

console.log = _=>{}

Blindly casting the type to E is not "type safe" because of the potential for anything to be thrown in JS and for any downstream library to throw an error. Errors being `unknown` is the only type safe option. It is completely misleading and therefore the opposite of "type safe" to let the error be whatever is passed in via generic. More realistically if your safeAwait checked for certain likely/expected errors and would only return those in the tuple, else throw on unexpected errors, then you could say it was type safe, because you would be avoiding type not-safety lies to yourself/colleagues/codebase. Another approach could be wrapping the error in a custom type (there are more options now thanks to `Error.cause`) and that could have some logic to help with keeping safeAwait() actually type safe. Otherwise this is a dangerous lesson!

There's another reason this won't be accepted by TC39 that's a lot more fundamental than bikeshedding the syntax: the "error" value in the tuple could be falsy or even null or undefined, which means it cannot be safely used to determine whether the expression threw or not. This is a potentially huge (if rare) footgun.

Monads

so basically a lua pcall?

Once I used Rust for a while then I returned back again to frontend development and the moment I had to handle some errors using try-catch, I felt extreme withdrawals ngl.

I wonder if a walrus “:=“ operator would work.

The problem with all the libraries is to enforce them.
Developers will always go the shortest way, even in my “own” projects when I tried to be strict and using the libraries it never worked out as i simply forgot it sometimes.

A VS code plugin at this point in combination with an librar could fix this..

That's great, but then if we're writing the UI, we have to perform conditionally rendering for each result reading? That doesn't sound fun to me, personally I prefer the error boundary approach 😂

I commented about this proposal on your video about JS error handling a week or two ago, and the interim safeawait/tuple hack. 🤓

You are wayyyyy too generous in your appraisal of my trustworthiness.

I know a lot about a few type-related niches and virtually nothing about all the other stuff developers use to be productive, so I'd be extremely wary of any opinions I happen to express that stray outside those subjects 🥸

The worst part is, that can throw anything (null, string, promise...), not just Error

when you started to write your version of ?= i was like “HOLD THE FU** UP… YOU CAN OVERLOAD OPERATORS???!?!??!???!!111?!!!”

a boy* can dream

*(old af)

Does Rxjs fix any of this....i thought it did ?

My solution for error handling is to not throw errors except when there's a clearly invalid/contradictory state. Instead, I return an enum value and make you do a `typeof` check or else you can't use my return type.

Wrap error-prone calls like fetch() and fs.readFile() in try/catch blocks and even dig into source code and specs to figure out what errors can be thrown—but always include an "unknown error" result just in case!