# function level try/catch
**URL:** https://es.discourse.group/t/function-level-try-catch/630
**Category:** đź’ˇ Ideas
**Tags:** proposal
**Created:** [February 2, 2021, 1:22pm UTC](https://es.discourse.group/t/function-level-try-catch/630 "2021-02-02T13:22:04Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@ondrejvelisek](https://es.discourse.group/u/ondrejvelisek)
#### Post date: [February 2, 2021, 1:22pm UTC](https://es.discourse.group/t/function-level-try-catch/630/1 "2021-02-02T13:22:04Z")
Hi,
have anyone thought about this?
```javascript
try function fnName() {
...
} catch() {
....
}
```
it would fit to other features well
```javascript
try async function fnName1() { ... } catch() { ... }
const fnName2 = try () => { ... } catch() { ... }
```
"try async function" even sounds right to me. What do you think?
---
### Author:  [@aclaymore](https://es.discourse.group/u/aclaymore)
#### Post date: [February 2, 2021, 10:29pm UTC](https://es.discourse.group/t/function-level-try-catch/630/2 "2021-02-02T22:29:29Z")
Hi @ondrejvelisek!
What do you see as the main problem this is solving?
The only benefit I can see is for catching default assignments, as there is no way of catching those at the moment.
```javascript
// not possible to catch this -> vvvvvvvvvvvvvvvvvv ❌
function functionName(arg1, arg2 = functionMightThrow(arg1)) {
try {
} catch (err) {
// but I can access function arguments here âś…
}
}
```
```javascript
try function functionName(arg1, arg2 = functionMightThrow(arg1)) {
...
} catch (err) {
// can catch `functionMightThrow` âś…
// but no access to function arguments ❌
}
```
---
### Author:  [@ondrejvelisek](https://es.discourse.group/u/ondrejvelisek)
#### Post date: [February 3, 2021, 8:22am UTC](https://es.discourse.group/t/function-level-try-catch/630/3 "2021-02-03T08:22:55Z")
I was thinking just about readabĂity. Did not think about catching default arguments. What a great point! it syntactically make sense, since arguments follows "try" keyword. I'm a bit afraid catch block without arguments would be a bit weak since developer would not be able to log them. But still could be usefull in some cases.
---
### Author:  [@ljharb](https://es.discourse.group/u/ljharb)
#### Post date: [February 3, 2021, 2:19pm UTC](https://es.discourse.group/t/function-level-try-catch/630/4 "2021-02-03T14:19:07Z")
How is this more readable?
When i look at it, i don’t know if this is running the try/catch on invocation or at definition time.
How would it work on async functions? The catch would be outside the expected await boundary, but async functions only reject and never throw.
---
### Author:  [@ondrejvelisek](https://es.discourse.group/u/ondrejvelisek)
#### Post date: [February 3, 2021, 3:49pm UTC](https://es.discourse.group/t/function-level-try-catch/630/5 "2021-02-03T15:49:42Z")
Another great point about missleading invocation vs. definition context. Thanks for that.
Where do you see the problem with async functions? Could you place an example?
---
### Author:  [@ljharb](https://es.discourse.group/u/ljharb)
#### Post date: [February 3, 2021, 4:04pm UTC](https://es.discourse.group/t/function-level-try-catch/630/6 "2021-02-03T16:04:07Z")
an async function never produces an exception, only a rejected promise - so the `catch` wouldn't have anything to catch. If it _did_ implicitly `await` the rejected promise and catch it, it'd be weird to be able to use `await` in that catch block outside the body of the async function.
---
### Author:  [@ondrejvelisek](https://es.discourse.group/u/ondrejvelisek)
#### Post date: [February 3, 2021, 4:31pm UTC](https://es.discourse.group/t/function-level-try-catch/630/7 "2021-02-03T16:31:00Z")
I see.
```javascript
try async function fnName() {
...
} catch() {
await someAsyncFn(); // this await seems weird
}
```
Do you see some elegant option to solve it?
---
### Author:  [@ljharb](https://es.discourse.group/u/ljharb)
#### Post date: [February 3, 2021, 5:42pm UTC](https://es.discourse.group/t/function-level-try-catch/630/8 "2021-02-03T17:42:08Z")
I think the elegant solution is to have the try/catch inside the function, as already works.
---
### Author:  [@rumkin](https://es.discourse.group/u/rumkin)
#### Post date: [February 3, 2021, 6:07pm UTC](https://es.discourse.group/t/function-level-try-catch/630/9 "2021-02-03T18:07:50Z")
I think there are more blocks could be "catchful" without the need of wrapping them in `try` block. It's just a redundant construction in some cases.
```javascript
for await (const chunk of stream) {
// throw something
}
catch (err) {
// handle error
}
finally {
stream.close()
}
```
The logic looks pretty straightforward: if a block has catch or finally statement it assumed as wrapped with try.
---
### Author:  [@ondrejvelisek](https://es.discourse.group/u/ondrejvelisek)
#### Post date: [February 3, 2021, 6:19pm UTC](https://es.discourse.group/t/function-level-try-catch/630/10 "2021-02-03T18:19:18Z")
I would strongly vote for keeping the try keyword e.g.
```javascript
try for await (const chunk of stream) {
// throw something
}
catch (err) {
// handle error
}
finally {
stream.close()
}
```
However great idea to generalize it for other code blocks. Thanks.
---
### Author:  [@aclaymore](https://es.discourse.group/u/aclaymore)
#### Post date: [February 4, 2021, 8:52pm UTC](https://es.discourse.group/t/function-level-try-catch/630/11 "2021-02-04T20:52:33Z")
fyi callers shouldn't need to close streams in finally blocks. Iterators either complete (`done: true`) or get an early `return`.
```javascript
const stream = {
[Symbol.iterator]() {
const values = [1, 2, 3][Symbol.iterator]();
return {
next: values.next.bind(values),
return() {
console.log('clean up stream early');
},
}
}
}
for (const v of stream) {
console.log(v);
if (v === 2) {
throw new Error('test');
}
}
// logs: 1, 2, clean up steam early
```
* * *
Also somewhat related is the Explicit Resource Management proposal as it also builds on the `try` keyword [GitHub - tc39/proposal-explicit-resource-management: ECMAScript Explicit Resource Management](https://github.com/tc39/proposal-explicit-resource-management)
```javascript
try using (const handle = acquireFileHandle()) { // critical resource
...
} // implicit cleanup
```