Comment by im-a-baby | Hacker News Reader

Comment by im-a-baby | Hacker News Reader

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.

> 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.

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.

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.

This config file is likely mounted in container, possibly different on different environemnts - ie. not "embedded", not "known at compile time".

And so failure is a user mistake, not a programmer mistake, and should be handled as such. The programmer and the user being the same person is irrelevant.

The difference is that the config is loaded at bootstrap stage - if it fails, starting service fails, there is not much to handle other than crash and supervisor (ie. k8s or whatever) will try to start it again.

You would likely exit. Crashing on invalid user input would be nonsensical.

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

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.

No thanks, exceptions are awful.

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

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.

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

Reply on news.ycombinator.com