Commit 956926ee authored by Rob Pike's avatar Rob Pike

Language FAQ: update the entry on exceptions.

R=rsc, iant
CC=golang-dev
https://golang.org/cl/824045
parent 065ebe8b
......@@ -282,20 +282,19 @@ This remains an open issue.
<h3 id="exceptions">
Why does Go not have exceptions?</h3>
<p>
Exceptions are a similar story. A number of designs for exceptions
have been proposed but each adds significant complexity to the
language and run-time. By their very nature, exceptions span functions and
perhaps even goroutines; they have wide-ranging implications. There
is also concern about the effect they would have on the
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>
Like generics, exceptions remain an open issue.
We believe that coupling the usual idea of exceptions to a control
structure, as in the <code>try-catch-finally</code> idiom, results in
convoluted code. It also tends to encourage programmers to label
too many ordinary errors, such as failing to open a file, as
exceptional. And then the type system gets mixed in.
</p>
<p>
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>
<h3 id="assertions">
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment