3 ms·

I think it's fine to add syntactic sugar for panic. The standard library already has similar functionality, like regexp.MustCompile. And personally, I've implem

I think it's fine to add syntactic sugar for panic. The standard library already has similar functionality, like regexp.MustCompile. And personally, I've implemented a Must function in many services. E.g. you try to parse a config file during service startup and parsing fails. There is no recourse from such an error. I'm sure I'm not the only one who has implemented such functionality, so why not add it to the language? Regarding the guard keyword, the author's proposal doesn't make sense. The guard call comes after the function call that produces the error, so it's not clear what is being guarded. I guess it's the error being wrapped in the guard message, but explaining that clearly in plain English is quite hard. I agree that context is important however. But maybe the Go team is finally ready to admit that stack traces are more useful than error messages. I'd be fine to know that, for example, an error occurred opening a file and having the language provide a full stack trace of where the error happened. I can do without the custom crafted error messages.

deleted 4y ago
[deleted]
bogota 4y ago
Panic at compile and run time are two very different things. must will panic before you ship your code to production no should want to make panic at runtime look nice
- fuckstick 4y ago
  You are gravely mistaken. MustCompile* if it fails panics at runtime. Go doesn’t have a general purpose compile time execution feature. That’s all Must does - is make runtime panic look nice. * MustCompile if you are unfamiliar - the compile refers to the compilation of the regular expression - which is always done at runtime.
  - bogota 4y ago
    Ah yeah i was remembering wrong. I normally have this setup as a package level variable and then build and test. But yes its on the test that it’s actually caught
melony 4y ago
We should set the syntax as "try... catch" and call the feature "exceptions". It will be revolutionary for Go.
- dehrmann 4y ago
  - doctor_eval 4y ago
    But that’s the opposite of what Go did. I think they always knew generics were important, but it just took ages to come up with a design that was satisfactory. Compare to Java, whose generics had so many compromises (type erasure) that I hated them. I really don’t think a quality gate is a problem, even if it’s sometimes inconvenient.
- XorNot 4y ago
  I do have a lot of trouble figuring out how Go's error handling is meaningfully different in user experience here. Errors as values seems to sound better in theory then in practice, since in practice everything is type Error, and then I either expect enough from the error to do something about it, or I don't. Which... Is exactly how I use exceptions in Python, replete with mostly having no idea what will get thrown. But Go makes it somewhat worse because most "error values" are just formatted strings, not actual types.
- grey-area 4y ago
  No thanks, exceptions are awful.
randomdata 4y ago
> And personally, I've implemented a Must function in many services. E.g. you try to parse a config file during service startup and parsing fails. regexp.MustCompile exists to catch programmer mistakes. You've presumably done your testing and when you ship the software you believe the regexp is correct and it should be impossible to fail, so if it still fails, something exceptional has happened; an exception as we call them in the biz. What you are doing when reading a config file is dealing with user mistakes. These are not exceptional, they are very much expected to happen and when they do you would traditionally want to provide useful feedback to the user, not simply crash. This may be something that people do, but it isn't what you'd want them to do. panic/recover are intended for exceptions, not errors. Why make it easier for developers to do silly things? In the rare cases where you actually have exceptions to deal with, a little extra work to make the situation clear to the reader is okay.
- im-a-baby 4y ago
  Your distinction between user and programmer doesn’t make sense to me. I typed the regex and I typed the config file. Why is a regex syntax error different than a YAML syntax error? Both are irrecoverable errors for my programs.
  - randomdata 4y ago
    The difference is that the regexp is embedded in your code as part of your code and won't change after you've shipped your code. It can only panic if your code is flawed. If the compiler was smarter, it'd be a compiler error. It only ends up a runtime concern because the compiler isn't smart enough to interpret your regular expressions to find your mistakes. If you were loading the regexp from an alterable file at runtime, to allow the user to change it after the program is shipped, you wouldn't use regexp.MustCompile. You would use regexp.Compile and gracefully deal with any errors that the user may have made. If you are talking about compile-time configuration, where once your program is built it won't change, why would you use YAML when you could simply use language-native variables/constants with actual compile-time safety? Regexps can improve on some programming problems over writing the equivalent code, so it's a good tradeoff in some cases. YAML is never nicer than the equivalent code.

deleted 4y ago

[deleted]

bogota 4y ago

Panic at compile and run time are two very different things. must will panic before you ship your code to production no should want to make panic at runtime look nice

fuckstick 4y ago
You are gravely mistaken. MustCompile* if it fails panics at runtime. Go doesn’t have a general purpose compile time execution feature. That’s all Must does - is make runtime panic look nice. * MustCompile if you are unfamiliar - the compile refers to the compilation of the regular expression - which is always done at runtime.
- bogota 4y ago
  Ah yeah i was remembering wrong. I normally have this setup as a package level variable and then build and test. But yes its on the test that it’s actually caught

melony 4y ago

We should set the syntax as "try... catch" and call the feature "exceptions". It will be revolutionary for Go.

dehrmann 4y ago
- doctor_eval 4y ago
  But that’s the opposite of what Go did. I think they always knew generics were important, but it just took ages to come up with a design that was satisfactory. Compare to Java, whose generics had so many compromises (type erasure) that I hated them. I really don’t think a quality gate is a problem, even if it’s sometimes inconvenient.
XorNot 4y ago
I do have a lot of trouble figuring out how Go's error handling is meaningfully different in user experience here. Errors as values seems to sound better in theory then in practice, since in practice everything is type Error, and then I either expect enough from the error to do something about it, or I don't. Which... Is exactly how I use exceptions in Python, replete with mostly having no idea what will get thrown. But Go makes it somewhat worse because most "error values" are just formatted strings, not actual types.
grey-area 4y ago
No thanks, exceptions are awful.

randomdata 4y ago

> And personally, I've implemented a Must function in many services. E.g. you try to parse a config file during service startup and parsing fails. regexp.MustCompile exists to catch programmer mistakes. You've presumably done your testing and when you ship the software you believe the regexp is correct and it should be impossible to fail, so if it still fails, something exceptional has happened; an exception as we call them in the biz. What you are doing when reading a config file is dealing with user mistakes. These are not exceptional, they are very much expected to happen and when they do you would traditionally want to provide useful feedback to the user, not simply crash. This may be something that people do, but it isn't what you'd want them to do. panic/recover are intended for exceptions, not errors. Why make it easier for developers to do silly things? In the rare cases where you actually have exceptions to deal with, a little extra work to make the situation clear to the reader is okay.

im-a-baby 4y ago
Your distinction between user and programmer doesn’t make sense to me. I typed the regex and I typed the config file. Why is a regex syntax error different than a YAML syntax error? Both are irrecoverable errors for my programs.
- randomdata 4y ago
  The difference is that the regexp is embedded in your code as part of your code and won't change after you've shipped your code. It can only panic if your code is flawed. If the compiler was smarter, it'd be a compiler error. It only ends up a runtime concern because the compiler isn't smart enough to interpret your regular expressions to find your mistakes. If you were loading the regexp from an alterable file at runtime, to allow the user to change it after the program is shipped, you wouldn't use regexp.MustCompile. You would use regexp.Compile and gracefully deal with any errors that the user may have made. If you are talking about compile-time configuration, where once your program is built it won't change, why would you use YAML when you could simply use language-native variables/constants with actual compile-time safety? Regexps can improve on some programming problems over writing the equivalent code, so it's a good tradeoff in some cases. YAML is never nicer than the equivalent code.