3 ms·

a isn't used so it won't ;p Honestly the thing that I think lacks more is macros. With macros it would be trivial to write a := Must!(f()) that * assigns

• adtac 3y ago
  b, err := os.ReadFile(path) if err != nil { return nil, fmt.Errorf("read %s: %w", path, err) } is so much better than b := Must!(os.ReadFile(path)) because when things go wrong, I have exactly the right amount of information I want. Assigning to err magically (it's not even mentioned in the source code) is exactly the kind of thing that'll turn out to be the cause of a subtle bug 6 months later. Why not spend the a couple of extra lines thinking about the error when the context is still in your head? Additionally I like how error handling acts as a visual delimiter, especially when you use meaningful fmt.Errorfs as strings are usually highlighted with a different colour, making it easy to quickly jump through code.
  • masklinn 3y ago
    > I have exactly the right amount of information I want. Really? Because `ReadFile` already adds the path to the context, so what you actually get is read /tmp/foo: open /tmp/foo: no such file or directory which is more confusing than "the right amount of information". Furthermore nothing precludes `Must!` taking a prefix and wrapping automatically, does it? > Assigning to err magically (it's not even mentioned in the source code) is exactly the kind of thing that'll turn out to be the cause of a subtle bug 6 months later. What bug? It's assigning and returning, the only situation where you'd have "a subtle bug" is if you didn't check the previous call and overwrote its error, which is exactly what you get with the code you propose.
• Mawr 3y ago
  Macros are a lazy design cop-out. They subvert the entire point of having a language in the first place - a shared understanding.