New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: allow main.main to optionally return an error #27328
Comments
Indeed, the Error Handling overview says: It would be shorter and clearer to write instead:
It would be even shorter, and I think even clearer, if
|
I too often end up writing three line main functions that call another function which returns an error, but I think if handle blocks were accepted then I could just put that code into the handle block and not use the wrapper, so this wouldn't be as helpful. Anyway, if main returns a value, why not have it be an int for the error code? And why not have main take a slice of os.Args? Those are both common in other languages, so I assume it was omitted for a reason. |
I'm not sure I understand correctly, but would it be addressed if we special-case
I think even if we allow |
It could just be a default handler for Or I could just keep writing the explicit code that I already do. It's slightly simpler with the draft-suggestion |
Similar suggestions are to let |
Well, Go's I'm also not sure if "programs return
Yeah, I'm not sure why it wasn't |
I suggest a read through the feedback wiki Most of it is counter-proposals; I suspect the next draft will be rather different :-) In non-returning functions (main & goroutines) I suspect a "default handler" -- or explicit one that doesn't os.Exit() -- would |
Oh, I'm sure that the next Error Handling draft will be rather different. I just wanted to write this idea down before I forgot. |
Related: #24869, which proposed that main.main be allowed to return an integer exit code (but was quickly rejected). |
This seems like a clear "no" to me. If anything, the new handle-check proposal is an argument against doing this, since if we adopt that proposal you'd be able to write:
I see very little compelling benefit here and I strongly disagree with establishing a standard handling of what happens when main returns an error. Your example of by default printing the error and exit 1 is one possibility but there are plenty of others. Better to let main be in charge of that. More generally, we've already made the decision about what main is. I don't see a strong reason here to reopen it. |
The spec says that "The main package must have package name main and declare a function main that takes no arguments and returns no value [emphasis added]."
I propose to additionally allow returning
error
. Combined with thecheck
and default-handler mechanisms suggested in the Error Handling Go 2 Draft Design, this could reduce some boilerplate. It would be equivalent to:This is admittedly sugar, but these days, I write that trivial
main
-calls-main1
dance in most of mypackage main
s. For example:To be clear,
func main() { etc }
that returned no value would still be valid, and have unchanged semantics.This is similar to issue #21111 but this one is for main functions and that one is for testing functions (including test examples, which are somewhat similar to main programs).
The text was updated successfully, but these errors were encountered: