3 ms·

OP has never heard of panic() and recover(), which are awful things that should not exist. I'll speculate that he hasn't used a language with a usable sum type

OP has never heard of panic() and recover(), which are awful things that should not exist. I'll speculate that he hasn't used a language with a usable sum type either, because I'd expect people who have been exposed to this would take issue with the idea of expanding every 5 line method to 40 lines of mostly error handling.

rubiquity 13y ago
> OP has never heard of panic() and recover(), which are awful things that should not exist. OP is using panic in the Heartbleed script he wrote. Source highlighted here: https://github.com/FiloSottile/Heartbleed/blob/master/bleed/heartbleed.go#L33-L47 https://github.com/FiloSottile/Heartbleed/blob/master/bleed/...
- sdegutis 13y ago
  Ah yes, very good examples of how Go's error handling needs improvement.
  - NateDad 13y ago
    Uh, no. You shouldn't use panic for error handling. You should basically never use panic unless you have some small bit of recursive algorithm inside your package that you want to be able to easily unwind. For general error handling you should only ever use error returns.
- FiloSottile 13y ago
  Please consider that I wrote in a time measured better in minutes.
  - rubiquity 13y ago
    I'm not criticizing your use of it, just showing the other person that you do know what panic is because you used it.
FiloSottile 13y ago
panic() is awful. Right. But is so much not a pattern. Sum, Max, Min are pain points that surprised me indeed. As for error handling I argue that it's a good thing. Really, it forces to decide what you do with your errors, and snippet expanders are there for a reason if you need to handle them all in the same way.
- azth 13y ago
  > Sum, Max, Min are pain points that surprised me indeed. I doubt the parent post meant sum as you used it. Look up "sum type" or "tagged union". Explicit + concise error handling are not mutually exclusive.
- anonymoushn 13y ago
  Sorry, I don't mean to talk about Sum/Max/Min. I mean to talk about Either<A,B>, which is the appropriate return type for almost every Go function. In the presence of this type, the "40 lines of mostly error handling" can then be reduced most of the way back to 5 lines using some function or control-flow construct that maps over the left half (or whichever half is chosen to not hold the exception) only. Here's this in a really ugly language I would never recommend to anyone: http://stackoverflow.com/questions/3496304/how-do-i-process-returned-either http://stackoverflow.com/questions/3496304/how-do-i-process-... And in a reasonable language: http://stackoverflow.com/questions/13503965/mapping-over-eithers-left http://stackoverflow.com/questions/13503965/mapping-over-eit... Edit: See also wting's comment below https://news.ycombinator.com/item?id=7562702 https://news.ycombinator.com/item?id=7562702

rubiquity 13y ago

> OP has never heard of panic() and recover(), which are awful things that should not exist. OP is using panic in the Heartbleed script he wrote. Source highlighted here: https://github.com/FiloSottile/Heartbleed/blob/master/bleed/heartbleed.go#L33-L47 https://github.com/FiloSottile/Heartbleed/blob/master/bleed/...

sdegutis 13y ago
Ah yes, very good examples of how Go's error handling needs improvement.
- NateDad 13y ago
  Uh, no. You shouldn't use panic for error handling. You should basically never use panic unless you have some small bit of recursive algorithm inside your package that you want to be able to easily unwind. For general error handling you should only ever use error returns.
FiloSottile 13y ago
Please consider that I wrote in a time measured better in minutes.
- rubiquity 13y ago
  I'm not criticizing your use of it, just showing the other person that you do know what panic is because you used it.

FiloSottile 13y ago

panic() is awful. Right. But is so much not a pattern. Sum, Max, Min are pain points that surprised me indeed. As for error handling I argue that it's a good thing. Really, it forces to decide what you do with your errors, and snippet expanders are there for a reason if you need to handle them all in the same way.

azth 13y ago
> Sum, Max, Min are pain points that surprised me indeed. I doubt the parent post meant sum as you used it. Look up "sum type" or "tagged union". Explicit + concise error handling are not mutually exclusive.
anonymoushn 13y ago
Sorry, I don't mean to talk about Sum/Max/Min. I mean to talk about Either<A,B>, which is the appropriate return type for almost every Go function. In the presence of this type, the "40 lines of mostly error handling" can then be reduced most of the way back to 5 lines using some function or control-flow construct that maps over the left half (or whichever half is chosen to not hold the exception) only. Here's this in a really ugly language I would never recommend to anyone: http://stackoverflow.com/questions/3496304/how-do-i-process-returned-either http://stackoverflow.com/questions/3496304/how-do-i-process-... And in a reasonable language: http://stackoverflow.com/questions/13503965/mapping-over-eithers-left http://stackoverflow.com/questions/13503965/mapping-over-eit... Edit: See also wting's comment below https://news.ycombinator.com/item?id=7562702 https://news.ycombinator.com/item?id=7562702