6 ms·

> This is a very interesting situation (and not a very common one for me) because it is where Go’s simple errors as values decisions shines. Doing this kind of

by junke 10y ago

> This is a very interesting situation (and not a very common one for me) because it is where Go’s simple errors as values decisions shines. Doing this kind of thing with exceptions would be pretty clumsy, [...] Just because a language supports exceptions does not mean you always have to use them. You can always use a helper function to catch any error and return it as a value.

fizzbatter 10y ago
Wouldn't that basically be replicating a return value-error approach, in a more cumbersome way though? You could argue that Go can use Exceptions in the same manner as X lang too, by using panic and recover... but most people seem to not like that. With Go and Rust, return value error handling is just simply nice. There's no question about if a function might error out, just look at the signature.
- junke 10y ago
  > Wouldn't that basically be replicating a return value-error approach, in a more cumbersome way though? This would not be "replicating" anything, exceptions already are values in most languages. The only thing to do is wrap your call with a function, like "err = catch-all(expr)". > ou could argue that Go can use Exceptions in the same manner as X lang too, by using panic and recover... Except that it would be cumbersome ;-) because panic/recover works only in combination with defer[0]. > With Go and Rust, return value error handling is just simply nice. Using non-exceptional control flow for errors can be useful depending on the circumstances. Using exceptions is simply nice in many other cases. > There's no question about if a function might error out, just look at the signature. Just look at the documentation. Code defensively. [0] http://stackoverflow.com/q/3413389/124319 http://stackoverflow.com/q/3413389/124319
  - junke 10y ago
    Just to clarify: err = catch-all(expr) If your language does not provide a similar tool, you can't just use a function because "expr" is evaluated before the function is called. I had Lisp macros in mind when writing this. A poor man's approach that is still generic is to wrap the expression in a closure: err = catch-all(() -> expr) Not too cumbersome, but YMMV.

by junke 10y ago

fizzbatter 10y ago

Wouldn't that basically be replicating a return value-error approach, in a more cumbersome way though? You could argue that Go can use Exceptions in the same manner as X lang too, by using panic and recover... but most people seem to not like that. With Go and Rust, return value error handling is just simply nice. There's no question about if a function might error out, just look at the signature.

junke 10y ago
> Wouldn't that basically be replicating a return value-error approach, in a more cumbersome way though? This would not be "replicating" anything, exceptions already are values in most languages. The only thing to do is wrap your call with a function, like "err = catch-all(expr)". > ou could argue that Go can use Exceptions in the same manner as X lang too, by using panic and recover... Except that it would be cumbersome ;-) because panic/recover works only in combination with defer[0]. > With Go and Rust, return value error handling is just simply nice. Using non-exceptional control flow for errors can be useful depending on the circumstances. Using exceptions is simply nice in many other cases. > There's no question about if a function might error out, just look at the signature. Just look at the documentation. Code defensively. [0] http://stackoverflow.com/q/3413389/124319 http://stackoverflow.com/q/3413389/124319
- junke 10y ago
  Just to clarify: err = catch-all(expr) If your language does not provide a similar tool, you can't just use a function because "expr" is evaluated before the function is called. I had Lisp macros in mind when writing this. A poor man's approach that is still generic is to wrap the expression in a closure: err = catch-all(() -> expr) Not too cumbersome, but YMMV.