mirror of https://github.com/rust-lang/rfcs
Correct a few more references to `try` in RFC 243
This commit is contained in:
parent
d9e79e4c57
commit
ee281d7119
|
@ -61,11 +61,11 @@ Naturally, in this case the types of the "exceptions thrown by" `foo()` and
|
||||||
`bar()` must unify. Like the current `try!()` macro, the `?` operator will also
|
`bar()` must unify. Like the current `try!()` macro, the `?` operator will also
|
||||||
perform an implicit "upcast" on the exception type.
|
perform an implicit "upcast" on the exception type.
|
||||||
|
|
||||||
When used outside of a `try` block, the `?` operator propagates the exception to
|
When used outside of a `catch` block, the `?` operator propagates the exception to
|
||||||
the caller of the current function, just like the current `try!` macro does. (If
|
the caller of the current function, just like the current `try!` macro does. (If
|
||||||
the return type of the function isn't a `Result`, then this is a type error.)
|
the return type of the function isn't a `Result`, then this is a type error.)
|
||||||
When used inside a `try` block, it propagates the exception up to the innermost
|
When used inside a `catch` block, it propagates the exception up to the innermost
|
||||||
`try` block, as one would expect.
|
`catch` block, as one would expect.
|
||||||
|
|
||||||
Requiring an explicit `?` operator to propagate exceptions strikes a very
|
Requiring an explicit `?` operator to propagate exceptions strikes a very
|
||||||
pleasing balance between completely automatic exception propagation, which most
|
pleasing balance between completely automatic exception propagation, which most
|
||||||
|
@ -203,7 +203,7 @@ are merely one way.
|
||||||
Err(e) => break 'here Err(e.into())
|
Err(e) => break 'here Err(e.into())
|
||||||
}
|
}
|
||||||
|
|
||||||
Where `'here` refers to the innermost enclosing `try` block, or to `'fn` if
|
Where `'here` refers to the innermost enclosing `catch` block, or to `'fn` if
|
||||||
there is none.
|
there is none.
|
||||||
|
|
||||||
The `?` operator has the same precedence as `.`.
|
The `?` operator has the same precedence as `.`.
|
||||||
|
@ -247,21 +247,18 @@ items.
|
||||||
|
|
||||||
Without any attempt at completeness, here are some things which should be true:
|
Without any attempt at completeness, here are some things which should be true:
|
||||||
|
|
||||||
* `try { foo() } ` = `Ok(foo())`
|
* `catch { foo() } ` = `Ok(foo())`
|
||||||
* `try { Err(e)? } ` = `Err(e.into())`
|
* `catch { Err(e)? } ` = `Err(e.into())`
|
||||||
* `try { try_foo()? } ` = `try_foo().map_err(Into::into)`
|
* `catch { try_foo()? } ` = `try_foo().map_err(Into::into)`
|
||||||
* `try { Err(e)? } catch { e => e }` = `e.into()`
|
|
||||||
* `try { Ok(try_foo()?) } catch { e => Err(e) }` = `try_foo().map_err(Into::into)`
|
|
||||||
|
|
||||||
(In the above, `foo()` is a function returning any type, and `try_foo()` is a
|
(In the above, `foo()` is a function returning any type, and `try_foo()` is a
|
||||||
function returning a `Result`.)
|
function returning a `Result`.)
|
||||||
|
|
||||||
## Feature gates
|
## Feature gates
|
||||||
|
|
||||||
The two major features here, the `?` syntax and the `try`/`catch`
|
The two major features here, the `?` syntax and `catch` expressions,
|
||||||
syntax, will be tracked by independent feature gates. Each of the
|
will be tracked by independent feature gates. Each of the features has
|
||||||
features has a distinct motivation, and we should evaluate them
|
a distinct motivation, and we should evaluate them independently.
|
||||||
independently.
|
|
||||||
|
|
||||||
# Unresolved questions
|
# Unresolved questions
|
||||||
|
|
||||||
|
@ -435,11 +432,9 @@ standard monadic bind to accommodate rich control flow like `break`,
|
||||||
|
|
||||||
* Don't.
|
* Don't.
|
||||||
|
|
||||||
* Only add the `?` operator, but not `try` and `try`..`catch`.
|
* Only add the `?` operator, but not `catch` expressions.
|
||||||
|
|
||||||
* Only add `?` and `try`, but not `try`..`catch`.
|
* Instead of a built-in `catch` construct, attempt to define one using
|
||||||
|
|
||||||
* Instead of a built-in `try`..`catch` construct, attempt to define one using
|
|
||||||
macros. However, this is likely to be awkward because, at least, macros may
|
macros. However, this is likely to be awkward because, at least, macros may
|
||||||
only have their contents as a single block, rather than two. Furthermore,
|
only have their contents as a single block, rather than two. Furthermore,
|
||||||
macros are excellent as a "safety net" for features which we forget to add
|
macros are excellent as a "safety net" for features which we forget to add
|
||||||
|
@ -477,7 +472,7 @@ It is possible to carry the exception handling analogy further and also add
|
||||||
|
|
||||||
`throw` is very simple: `throw EXPR` is essentially the same thing as
|
`throw` is very simple: `throw EXPR` is essentially the same thing as
|
||||||
`Err(EXPR)?`; in other words it throws the exception `EXPR` to the innermost
|
`Err(EXPR)?`; in other words it throws the exception `EXPR` to the innermost
|
||||||
`try` block, or to the function's caller if there is none.
|
`catch` block, or to the function's caller if there is none.
|
||||||
|
|
||||||
A `throws` clause on a function:
|
A `throws` clause on a function:
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue