Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does this improve upon Promises? #40

Open
JamesRamm opened this issue Sep 4, 2024 · 4 comments
Open

How does this improve upon Promises? #40

JamesRamm opened this issue Sep 4, 2024 · 4 comments

Comments

@JamesRamm
Copy link

I am struggling to see how this:

  const [requestError, response] ?= await fetch(
    "https://api.example.com/data"
  )

  if (requestError) {
    handleRequestError(requestError)
    return
  } 
  handleResponse(response)

is an improvement upon

 fetch("https://api.example.com/data")
   .then(handleResponse)
   .catch(handleError)

Can you expand upon this?
IMO the first two stated goals - Simplified Error Handling and Enhanced Readability are already addressed by the superior Promises API.

I can understand the motivation for this, if I approach from the angle of someone who has much more experience with async/await and not using Promises.

I also don't see how it improves security. You can equally overlook implementing checking the error response - if (requestError) - as omitting to implement a catch block.
Furthermore, your proposal seems to indicate that errors will no longer be thrown - they are 'swallowed' by the assignment operator and returned as a value. This means that if you do overlook checking the return value, you do not got a bunch of 'uncaught exception' warnings in the console, linters etc...
Granted there are ways of swallowing exceptions with try/catch and promises, but forgetting to implement a catch block in most standard use cases will result in such warning.
So, I actually see this proposal as a regression with regards to security in that respect.

@otaxhu
Copy link

otaxhu commented Sep 4, 2024

This is not only for Promises, it aims any kind of function (synchronous and asynchronous) or expressions (see #5)

In Promises regards, it solves "callback hell", callback indentation readability, try block indentation readability (if using await syntax), and error as values have been proven to be popular among developers.

Operator ?= has been replaced over try-expression syntax (see #4 #5)

@garretmh
Copy link

The proposal seems primarily useful for synchronous code. Promises can be turned into "result tuples" trivially:

const [error, value] = await fetch("https://api.example.com/data").then(
  (value) => [undefined, value],
  (error) => [error, undefined]
)

// With a wrapper function:
const result = (promise) => promise.then((val) => [undefined, val], (err) => [err, undefined])
const [error, value] = await result(fetch("https://api.example.com/data"))

@arthurfiorette
Copy link
Owner

The proposal seems primarily useful for synchronous code

For async code as well because it would provide a standard way of converting errors as values.

@Arlen22
Copy link

Arlen22 commented Sep 19, 2024

The one improvement for Promises is the ability to type check the tuple types after they are decoupled, if Typescript allows that at all. And it removes an extra .then(e => [undefined, e], e => [e]). That's all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants