You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+31-21Lines changed: 31 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,14 +13,16 @@
13
13
14
14
<br />
15
15
16
-
This proposal aims to address the ergonomic challenges of managing multiple, often nested, `try/catch` blocks that are necessary for handling operations that may fail at various points.
16
+
This proposal addresses the ergonomic challenges of managing multiple, often nested, `try/catch` blocks necessary for handling operations that may fail at various points.
17
17
18
18
Only the `catch (error) {}` block represents actual control flow, while no program state inherently depends on being inside a `try {}` block. Therefore, forcing the successful flow into nested blocks is not ideal.
19
19
20
20
<hr />
21
21
<br />
22
22
23
23
-[Try/Catch Is Not Enough](#trycatch-is-not-enough)
24
+
-[Status](#status)
25
+
-[Authors](#authors)
24
26
-[Caller's Approach](#callers-approach)
25
27
-[What This Proposal Does Not Aim to Solve](#what-this-proposal-does-not-aim-to-solve)
26
28
-[Type-Safe Errors](#type-safe-errors)
@@ -42,7 +44,6 @@ Only the `catch (error) {}` block represents actual control flow, while no progr
42
44
-[The Need for an `ok` Value](#the-need-for-an-ok-value)
43
45
-[Why a Proposal?](#why-a-proposal)
44
46
-[Help Us Improve This Proposal](#help-us-improve-this-proposal)
45
-
-[Authors](#authors)
46
47
-[Inspiration](#inspiration)
47
48
-[License](#license)
48
49
@@ -125,7 +126,23 @@ async function handle(request, reply) {
125
126
}
126
127
```
127
128
128
-
A `try` statement provide significant flexibility and arguably result in more readable code. A `try` statement is a statement that can be used wherever a statement is expected, allowing for concise and readable error handling.
129
+
A `try` statement provides significant flexibility and arguably results in more readable code. A `try` statement is a statement that can be used wherever a statement is expected, allowing for concise and readable error handling.
130
+
131
+
<br />
132
+
133
+
## Status
134
+
135
+
**Stage:** 0 \
136
+
**Champion:**_Actively looking for one_
137
+
138
+
_For more information see the [TC39 proposal process](https://tc39.es/process-document/)._
@@ -139,7 +156,7 @@ With that in mind, improvements in error handling can be approached in two ways:
139
156
140
157
```js
141
158
try {
142
-
constresult=work()
159
+
constvalue=work()
143
160
} catch (error) {
144
161
console.error(error)
145
162
}
@@ -149,12 +166,12 @@ With that in mind, improvements in error handling can be approached in two ways:
149
166
150
167
```js
151
168
functionwork() {
152
-
// Performs some operation
169
+
try {
170
+
// Performs some operation
153
171
154
-
if (error) {
155
-
return { status:"error", error }
156
-
} else {
157
-
return { status:"ok", data }
172
+
return { ok:true, value }
173
+
} catch (error) {
174
+
return { ok:false, error }
158
175
}
159
176
}
160
177
```
@@ -173,11 +190,11 @@ Ironically, these are precisely the kinds of functions where improved error hand
173
190
174
191
### Type-Safe Errors
175
192
176
-
The `throw` statement in JavaScript can throw any type of value. This proposal does not impose nor proposes any kind safety around error handling.
193
+
The `throw` statement in JavaScript can throw any type of value. This proposal does not impose nor propose any kind of safety around error handling.
177
194
178
195
- No generic error type for the proposed [Result](#result-class) class will be added.
179
196
- No catch branching based on error type will be added. See [GitHub Issue #43](https://github.com/arthurfiorette/proposal-try-operator/issues/43) for more information.
180
-
- No ways to annotate a callable to specify the error type it throws will be added.
197
+
- No way to annotate a callable to specify the error type it throws will be added.
181
198
182
199
For more information, also see [microsoft/typescript#13219](https://github.com/Microsoft/TypeScript/issues/13219). _()_
183
200
@@ -232,7 +249,7 @@ const result = _result
232
249
233
250
### Can be inlined.
234
251
235
-
Similar to `void`, `typeof`, `yield` and `new`:
252
+
Similar to `void`, `typeof`, `yield`, and `new`:
236
253
237
254
```js
238
255
array.map((fn) =>tryfn()).filter((result) =>result.ok) // works :)
@@ -334,7 +351,7 @@ A detailed discussion about this topic is available at [GitHub Issue #55](https:
334
351
335
352
### Void Operations
336
353
337
-
In scenarios where the successful result of a operation is not needed, it can be safely ignored:
354
+
In scenarios where the successful result of an operation is not needed, it can be safely ignored:
338
355
339
356
```js
340
357
functionwork() {
@@ -369,7 +386,7 @@ The `Result` class represents the form of the value returned by the `try` operat
369
386
370
387
A `Result` instance contains three properties:
371
388
372
-
- **`ok`**: A boolean indicating whether the expression executed successfully.
389
+
- **`ok`**: A boolean indicating whether the expression was executed successfully.
373
390
- **`error`**: The error thrown during execution, or `undefined` if no error occurred.
374
391
- **`value`**: The data returned from the execution, or `undefined` if an error occurred.
375
392
@@ -500,13 +517,6 @@ This proposal is in its early stages, and we welcome your input to help refine i
0 commit comments