1
0
mirror of https://github.com/golang/go synced 2024-11-13 18:20:32 -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:
Rob Pike 2010-04-07 16:03:12 -07:00
parent 065ebe8bd4
commit 956926ee31

View File

@ -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">