# Enhanced Try Syntax
**URL:** https://es.discourse.group/t/enhanced-try-syntax/2119
**Category:** š¦ Proposals
**Tags:** proposal
**Created:** [August 27, 2024, 7:52am UTC](https://es.discourse.group/t/enhanced-try-syntax/2119 "2024-08-27T07:52:33Z")
**Posts on this page:** 16
**Page:** 2
### Author:  [@mohsen1](https://es.discourse.group/u/mohsen1)
#### Post date: [October 2, 2024, 11:02am UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/21 "2024-10-02T11:02:21Z")
Hi everyone,
Thank you all for your valuable feedback and for engaging in this discussion.
**Getting Attention from TC39 Members**
I'm eager to move this proposal forward within the TC39 process and would appreciate any guidance on how to get the attention of TC39 members who might be interested in championing it. If anyone has suggestions or can facilitate an introduction to potential champions, I would be grateful.
**Prevalence of the Pattern**
I want to emphasize that the pattern of intentionally ignoring errors is widespread in JavaScript codebases. There are many scenarios where a thrown error is not critical, and developers choose to proceed without handling it explicitly. Providing a concise syntax for these cases can improve code readability and reduce boilerplate.
**Additional Use Cases:**
- **Non-Critical API Calls:**
- **Best-Effort Operations:**
- **Cleanup Tasks:**
- **Resource Release:**
**Examples from Other Languages**
This concept is not unique to JavaScript; several other languages provide mechanisms for succinct error handling when the error can be safely ignored.
- **C#:**
- **PHP:**
**Addressing Concerns About Bad Practices**
I understand the concerns about potentially encouraging bad practices by making it easier to ignore errors. However, developers are already employing these patterns extensively. By providing a concise and intentional syntax, we can make the code's intent clearer.
- **Intentional Ignoring:** Using `try` without `catch` makes it explicit that any errors are being deliberately ignored, as opposed to an accidental oversight.
- **Improved Readability:** Reducing boilerplate code allows developers to focus on the main logic, improving overall code readability.
- **Tooling Support:** Linters and code analysis tools can be configured to flag inappropriate use of empty `try` blocks, helping maintain code quality.
**Next Steps**
1. **Seeking a Champion:**
2. **Gathering More Feedback:**
Thank you again all for your time and insights
---
### Author:  [@aclaymore](https://es.discourse.group/u/aclaymore)
#### Post date: [October 2, 2024, 3:12pm UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/22 "2024-10-02T15:12:34Z")
Hi!
My personal feeeback remains the same as my previous comment.
> [@aclaymore](#):
>
> I'm currently not sure that it is so common that the slightly shorter syntax is worth the cost. `catch {}` is explicit that the intention is to ignore all exceptions.
Syntax changes can have a high cost, they require that teams ensure all the tools they use can handle the new syntax. e.g. Bundlers, minifiers, formatters, linters, code mods.
---
### Author:  [@mohsen1](https://es.discourse.group/u/mohsen1)
#### Post date: [October 2, 2024, 3:35pm UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/23 "2024-10-02T15:35:42Z")
I understand that this is going to cost a bunch of work for everyone involved to land. But as a user of JavaScript I would be happy to have this in the language.
Just today I wrote this code:
let response: Response | null = null;
try {
response = await route.request().response();
} catch {
// ignore trying to get response of the requests that are not successful
}
This could be written as
const response = try await route.request().response();
A ton of boilerplate, including the necessity to import and use types (Response) will be removed if this syntax is added to JavaScript.
---
### Author:  [@ljharb](https://es.discourse.group/u/ljharb)
#### Post date: [October 3, 2024, 2:58am UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/24 "2024-10-03T02:58:15Z")
I believe you can do `const response = await route.request().response().catch(() => null);` already?
---
### Author:  [@vikingair](https://es.discourse.group/u/vikingair)
#### Post date: [October 8, 2024, 5:42am UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/25 "2024-10-08T05:42:52Z")
Why not making best of two worlds? I considered writing my own proposal for it, but since this proposal is pretty close, I wanted rather to see if you agree about the proposed fix.
```js
const [err, data] = try JSON.parse(input);
// you can still ignore any errors easily, but it is much more explicit
const [, data] = try JSON.parse(input);
// similar for promise-like return values
const [err, response] = try await doRequest();
```
I wouldn't touch the "try" block by itself, as I believe that error handling should be done rather more explicitly, but I agree that the suggested syntax would increase the overall readability of the code.
Hence, this syntax change would improve the language.
I think it will be easier to get this proposal into JS. Would you agree?
---
### Author:  [@sgmonda](https://es.discourse.group/u/sgmonda)
#### Post date: [January 6, 2025, 11:24am UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/26 "2025-01-06T11:24:31Z")
I like the proposal but Iām a bit worried about āmaking easier to write good codeā also brings āmaking easier to write bad codeā.
I would encapsulate try-catch (with empty catch) inside util functions that make you happy using them. In fact I could find error ignoring useful with some existing bad API designs. But Iām not sure the language should make easy to ignore errors so silently.
With that in mind, maybe having many empty `catch () {}` in your code helps you to improve how you manage errors in your projects. Itās usually a code smell rather than a bad language design.
---
### Author:  [@mohsen1](https://es.discourse.group/u/mohsen1)
#### Post date: [January 6, 2025, 1:27pm UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/27 "2025-01-06T13:27:00Z")
I personally have given up on this proposal. There is no appetite to adopt such idea it seems. Not clear to me what makes JavaScript different than other languages that have the exact same feature thoughā¦
---
### Author:  [@arthurfiorette](https://es.discourse.group/u/arthurfiorette)
#### Post date: [January 20, 2025, 6:50pm UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/28 "2025-01-20T18:50:58Z")
What about [GitHub - arthurfiorette/proposal-try-expressions: Draft for ECMAScript Error Safe Assignment Operator](https://github.com/arthurfiorette/proposal-try-expressions)? It's the improved versionofm the past `proposal-safe-assignment-operator` and has almost all major concerns (as far as I know) solved. It might not have the best ergonomics, although this is more of a personal preference than anything else, but works.
---
### Author:  [@bramkamies](https://es.discourse.group/u/bramkamies)
#### Post date: [February 24, 2025, 3:11pm UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/29 "2025-02-24T15:11:10Z")
I really like how you identified the core problem with `try`; I've never looked at the language construct in separate parts like that. Beyond that I hope your proposal goes far.
Something that you may want to specify as a non-goal is the methods for `Result`. If you let methods to chain computation off results, then you will get a large amount of scope creep and bike-shedding about names and semantics.
If you add it as a non-goal to specify methods for `Result` then those can be discussed in a second proposal once the (syntax) primitive is in.
---
### Author:  [@Sukima](https://es.discourse.group/u/Sukima)
#### Post date: [March 3, 2025, 10:07pm UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/30 "2025-03-03T22:07:24Z")
In this proposal, what is the difference between `try something()` and `tryDoing(() => something())` where `tryDoing` might be:
```js
function tryDoing(task) {
try { return task() } catch (_ignored) {}
}
```
---
### Author:  [@bramkamies](https://es.discourse.group/u/bramkamies)
#### Post date: [March 5, 2025, 8:45am UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/31 "2025-03-05T08:45:00Z")
By comparison, here is `tryDoing` such that it matches `try something()` from the proposal:
```javascript
function tryDoing(task) {
try {
return [true, undefined, task()];
} catch (error) {
return [false, error, undefined];
}
}
// Note: The full Result class is omitted for brevity, focussing on the iterable-destructured assignment pattern instead.
const [ok, error, value] = tryDoing(something);
```
Differences:
1. Thrown errors are not ignored, instead captured and returned.
2. Besides the value and error being returned separately, a boolean marking the completion scenario.
---
### Author:  [@vikingair](https://es.discourse.group/u/vikingair)
#### Post date: [March 26, 2025, 5:26am UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/32 "2025-03-26T05:26:13Z")
It seems adoption of the community and dev influencers for the safe assignment are growing. There are already plenty different implementations available for wrapper functions trying to achieve something close.
It makes the code actually more readable. Especially, with a project setup using Go+TS. Making both more look alike.
This is the closest I could get with the following goals and no syntax adoption:
- minimalistic
- type-safe
- explicit
-\> [@backend/safe-assignment - JSR](https://jsr.io/@backend/safe-assignment)
---
### Author:  [@Nik](https://es.discourse.group/u/Nik)
#### Post date: [April 1, 2025, 7:53pm UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/33 "2025-04-01T19:53:23Z")
Hi gang! That's a great idea!!!
I was about to ask for TRY without CACHE, but thankfully I checked first if there is already something on the topic :)
Very often I need just the TRY, but I am required to have an empty cache, you know how it is :)
Also the idea for inline TRY is absolutely awesome!
To return undefined to be able to use directly like in the example of "mohsen1"
Yup, I want that too š
`let data = try JSON.parse(input) ?? {};`
---
### Author:  [@WebReflection](https://es.discourse.group/u/WebReflection)
#### Post date: [June 10, 2025, 7:54am UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/35 "2025-06-10T07:54:12Z")
for what is worth it, I do use that pattern except I return just `[null, result]` on success and `[error, null]` on failure, which is more aligned with old school NodeJS signatures and it plays nicely with 2.length arrays optimizations so it's:
```js
const [err, ok] = tryDoing(stuff, ...args);
```
If we had a native way to do the same it'd be awesome but I agree with the sentiment that it has a cost and it's trivial to implement explictly on userland so it adds little value ... maybe all we need is a popular and stable module that does just that and use it to avoid duplication (but then I can't stop thinking about leftPad situation).
---
### Author:  [@sxzz](https://es.discourse.group/u/sxzz)
#### Post date: [August 15, 2025, 9:04pm UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/36 "2025-08-15T21:04:28Z")
For those interested in experimenting with this proposal, you can try [GitHub - sxzz/tc39-try: Enable support for try expressions in JavaScript tools](https://github.com/sxzz/tc39-try) , which offers an implementation compatible with current JavaScript toolchains.
However, please note that this is a very early-stage proposal, and the tool itself is also experimental.
---
### Author:  [@7ombie](https://es.discourse.group/u/7ombie)
#### Post date: [August 27, 2025, 4:58pm UTC](https://es.discourse.group/t/enhanced-try-syntax/2119/37 "2025-08-27T16:58:32Z")
This is (yet) another example of why we need to stop complicating the JavaScript that browsers parse, and focus on languages that compile to JavaScript.
That migration would be a lot smoother, if those languages could output something closer to a binary JavaScript AST that could be executed by the engine more directly.
New features would only be added via the AST format, and would generally be low level, and support for JavaScript source code would become a legacy.
[Previous page](https://es.discourse.group/t/enhanced-try-syntax/2119.md?page=1)