4 ms·
How returning (val, err) is error prone? It's verbose but it's clear and definitely not error prone. I spent so much time working with Java and useless giant st
by Thaxll 7y ago
How returning (val, err) is error prone? It's verbose but it's clear and definitely not error prone. I spent so much time working with Java and useless giant stacktraces or with Python and people not knowing what to do inside a try / except.
- _hardwaregeek 7y agoIt's error prone in that you aren't forced to handle the error. In languages such as Rust or Haskell, you have a Result type which can either be an Ok(val) or an Err(err). In order to "unwrap" a Result, you have to check the error case. Basically there's a compile time guarantee that errors are handled.
- Thaxll 7y agoI'm not a Rust expert but afaik Rust doesn't enforce error checking since you explicitly need to unwrap(). It's very possible to panic because you forgot to check something. It's similar in Go since you can't compile with unused variable so you need to explicitly discard the error with _. Ex: result, _ := func() This is for multi-value returns, for single value you can even omit the _ https://golang.org/doc/effective_go.html#blank https://golang.org/doc/effective_go.html#blank
- jpittis 7y agoHaving unwrap() in your Rust code is like littering your code base with panic(). It’s not appropriate to use in most production code, but is convenient in prototypes, examples and tests. Your example re Go errors is incorrect. The go compiler allows you to ignore errors in returns without any compiler error. For example err := doThingThatErrs() and doThingThatErrs() are both valid Go code.
- Thaxll 7y agoMy example is correct I explained all of that, multi values -> need to omit, single value can ignore everything.
- jpittis 7y agoYup. I misspoke. We’re both right.
- edflsafoiewq 7y agoThere's nothing wrong with unwrap. It's just an assert. Even a[i] is just shorthand for a.get(i).unwrap(). Asserts are definitely appropriate in production code, just not for handling run-time errors.
- jbverschoor 7y agoThen how is this better than anything else? Except for syntactical sugar for: Try Return [Bla(), null] Catch err Return [null, err] End I do like this syntax better, bc the different scopes cause a lot of nesting
- djur 7y agoRepetition and verbosity in a language can create errors in at least two ways. First, by the developer losing track of which error case is which (and/or copy-pasting error-handling logic) and doing the wrong thing in the error case. Second, by reviewers who have become trained to notice and gloss over error-handling boilerplate not noticing when there's something wrong with a particular case. Concise languages can be more challenging to read because you have to understand more about each symbol/word in the language. But verbose languages can be more challenging to comprehend because there's a lot of symbols which don't signify anything.
- kartickv 7y agoInteresting perspective. Are you expressing an opinion about "explicit is better than implicit", or is your point on a different axis? I suppose concise / implicit is fine when the thing that's being hidden can't go wrong, like in: [i * 2 for i in 1...10] The loop counter increment logic can't possibly go wrong, so it's fine to not think about it. Regarding error-handling, don't you want to think about? If you're calling a() followed by b(), what should you do if a() fails? In some cases, b() shouldn't be called, but in others, it should, like deleting a temp file. And if you have to think about it, it's better to be explicit?
- wolco 7y agoyou have 'catch' to handle those cases. Try and catch are easy to notice when scanning the codebase.
- djur 7y agoMy preferences are that error handling is expressed in and enforced by the type system (Haskell's Maybe/Either, Rust's Result), that common error handling tasks be supported by the standard library and by specialized syntax when necessary (Haskell's many Monad/Applicative tools, Rust's "?" operator), and that if a developer neglects or chooses not to handle an error that the most likely outcome is that it bubbles up to some kind of top-level crash handler that terminates the current task and produces whatever useful diagnostics are possible (exceptions in many languages). To put it more simply: yes, the developer should have to think about what they do in the case of an error. And then the amount of work they do -- and the code produced, and thus the work reviewers have to do -- should be proportionate to how unusual the necessary error handling is. When I see explicit error handling, that signals to me "hey, this is an important case that we need to handle in a particular way".
- kerng 7y agoCopy/paste is very error prone. Golang code is full of it. I see lots of similarities between Visual Basic and Golang, incl. the passionate communities behind the languages.
- pjmlp 7y agoWith the difference that Visual Basic is an academic language full of needless features from Go's community point of view.
- mikeschinkel 7y agoVisual Basic is hardly academic; they is a tremendous amount of line-of-business code that has been written in VB over the past 25 years. But yeah, Go dev do not see VB's features as being "features."
- pjmlp 7y agoThe point was that many of VB.NET features are what many in the community attack as being academic and not worthy of being adopted by Go.
- mikeschinkel 7y agoGiven that I have worked with VB long before .NET even existed, I have a broader view of it than just the more recent criticisms. VB's biggest problem IMO is that it tried to compete with C# instead of maintaining its original raison d'être which was to be a highly productive tool that required very little programming skill to be able to start building real solutions for business use. But I digress...
- mikeschinkel 7y agoCurious, do you see other communities that are not passionate about their languages?