3 ms·
I find it ironic that golang refuses to introduce exceptions, but instead is slowly turning errors into a crappy substitute. I feel like a modern language shou
by nvarsj 4y ago
I find it ironic that golang refuses to introduce exceptions, but instead is slowly turning errors into a crappy substitute.
I feel like a modern language should do either two things with errors: exceptions, or a result monad. Since the language is GC'd and doesn't have language support to make a result type practical, it seems like exceptions are a no brainer.
- kajaktum 4y ago>Since the language is GC'd and doesn't have language support to make a result type practical, it seems like exceptions are a no brainer. Elaborate? What prevents Go from introducing result monad aside from the syntax?
- nvarsj 4y agoI'm sure it could introduce something _like_ a result monad, but with the associated very clunky/verbose syntax in golang which reduces to conditionals and lots of type casts. I guess this is sort of where error is going. Something like Rust's '?' operator comes to mind. Also, pattern matching with parameter extraction.
- deleted 4y ago[deleted]
- lowmagnet 4y agoThis functionality is really meant for situations where you do stuff like validate a struct for completeness (part of checking user input, often) and return a list of errors instead of failing at the first error. It's kinda a godsend for the kind of application I write.