Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in
Toggle navigation
G
golang
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Commits
Issue Boards
Open sidebar
go
golang
Commits
956926ee
Commit
956926ee
authored
Apr 07, 2010
by
Rob Pike
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Language FAQ: update the entry on exceptions.
R=rsc, iant CC=golang-dev
https://golang.org/cl/824045
parent
065ebe8b
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
13 additions
and
14 deletions
+13
-14
go_lang_faq.html
doc/go_lang_faq.html
+13
-14
No files found.
doc/go_lang_faq.html
View file @
956926ee
...
...
@@ -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"
>
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment