|
|
|
|
|
|
by moe
4703 days ago
|
|
|
Go seems to prefer that the decision that an error condition is treated as a panic is generally left to user code that is written with more awareness of what is exceptional in the context of the role of that code than standard library code has. That makes little sense in the context of ioWriters and, frankly, most contexts. How often do you write code where you deliberately want to be oblivious of IO errors? |
|
|
The existence of error returns means that the IO library function "not panicking" and the calling code being "oblivious of IO errors" are not equivalent.
I think the motivation for the Go convention of keeping panics internal and reducing to error returns in library APIs minimizing the potential downsides of the way unchecked exceptions are not part of the declared interface of functions and yet have a major effect on control flow. A convention of using panics (which amount to unchecked exceptions) only within logically bounded units is, IMO, a sensible approach to this.
(You could do this with checked exceptions, which require additional syntax in declarations. When you already have support multiple valued returns, I don't see that checked exceptions get you much that's worth making signatures more complicated.)