mirror of
https://github.com/golang/go
synced 2024-11-22 01:24:42 -07:00
Language FAQ: update the entry on exceptions.
R=rsc, iant CC=golang-dev https://golang.org/cl/824045
This commit is contained in:
parent
065ebe8bd4
commit
956926ee31
@ -282,20 +282,19 @@ This remains an open issue.
|
|||||||
<h3 id="exceptions">
|
<h3 id="exceptions">
|
||||||
Why does Go not have exceptions?</h3>
|
Why does Go not have exceptions?</h3>
|
||||||
<p>
|
<p>
|
||||||
Exceptions are a similar story. A number of designs for exceptions
|
We believe that coupling the usual idea of exceptions to a control
|
||||||
have been proposed but each adds significant complexity to the
|
structure, as in the <code>try-catch-finally</code> idiom, results in
|
||||||
language and run-time. By their very nature, exceptions span functions and
|
convoluted code. It also tends to encourage programmers to label
|
||||||
perhaps even goroutines; they have wide-ranging implications. There
|
too many ordinary errors, such as failing to open a file, as
|
||||||
is also concern about the effect they would have on the
|
exceptional. And then the type system gets mixed in.
|
||||||
libraries. They are, by definition, exceptional yet experience with
|
|
||||||
other languages that support them show they have profound effect on
|
|
||||||
library and interface specification. It would be nice to find a design
|
|
||||||
that allows them to be truly exceptional without encouraging common
|
|
||||||
errors to turn into special control flow that requires every programmer to
|
|
||||||
compensate.
|
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Like generics, exceptions remain an open issue.
|
Go takes a different approach. Instead of exceptions, it has couple
|
||||||
|
of built-in functions to signal and recover from truly exceptional
|
||||||
|
conditions. The recovery mechanism is executed only as part of a
|
||||||
|
function's state being torn down after an error, which is sufficient
|
||||||
|
to handle catastrophe but requires no extra control structures and,
|
||||||
|
when used well, can result in clean error-handling code.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<h3 id="assertions">
|
<h3 id="assertions">
|
||||||
|
Loading…
Reference in New Issue
Block a user