Hacker News new | ask | show | jobs
by dragonwriter 4712 days ago
Go supports exceptions (called "panics").

The substantive difference between Go and, e.g., Java with regard to exceptions is that Go builtin and standard library functions panic in a much narrower range of circumstances than Java's standard library. 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.

So, you could write the code in pretty much exactly the way you propose in Go; you'd just need to write a wrapper function around binary.Write that panics on errors.
1 comments
moe 4711 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?

link
dragonwriter 4711 days ago
> 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.)

link
moe 4711 days ago
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.

Seriously?

Does your test-suite exercise every potential I/O error and timeout on every single of your I/O calls?

link