TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Proposal: A built-in Go error check function, try

131 点作者 stablemap将近 6 年前

25 条评论

lunixbochs将近 6 年前
I implemented try() in Go five years ago with an AST preprocessor and used it in real projects, it was pretty nice: <a href="https:&#x2F;&#x2F;github.com&#x2F;lunixbochs&#x2F;og" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lunixbochs&#x2F;og</a><p>Here are some examples of me using it in error-check-heavy functions: <a href="https:&#x2F;&#x2F;github.com&#x2F;lunixbochs&#x2F;poxd&#x2F;blob&#x2F;master&#x2F;tls.go#L13" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lunixbochs&#x2F;poxd&#x2F;blob&#x2F;master&#x2F;tls.go#L13</a>
评论 #20101722 未加载
kstenerud将近 6 年前
If it were a keyword rather than a pseudo-function, I would support its addition. Psuedo-functions should not be allowed into the language, as they tend to have side effects that you wouldn&#x27;t expect from a function call (such as returning from caller to grandparent).<p>Some keyword that implies &quot;return if error&quot; so that you could then do:<p><pre><code> try v1, v2, v3 := someFunction() </code></pre> You could even make it a little bit smart, taking advantage of the return types of the function to automatically fill in named return values:<p><pre><code> func MyFunc(param int) (result int, err error) { result = 0 if param &gt; 0 { result = param + 10 } else { try p1, p2 := GetInternalValues(param) result = p1 * p2 } return result, err } </code></pre> where &quot;try p1, p2 := GetInternalValues(param)&quot; is syntactic sugar for (in this case):<p><pre><code> var p1, p2 int p1, p2, err = GetInternalValues(param) if err != nil { return result, err }</code></pre>
评论 #20109507 未加载
评论 #20103072 未加载
umurgdk将近 6 年前
I am strongly against this. `try` seems exactly like a function yet it is not acting like a function at all. People wouldn&#x27;t expecting calling a function may return from the caller. And there is a reason why golang doesn&#x27;t have macros. With macros all kind of craziness would be possible, and would really difficult to read different kind of projects&#x27; code.
评论 #20102229 未加载
评论 #20102057 未加载
评论 #20103926 未加载
评论 #20101887 未加载
评论 #20102933 未加载
abvdasker将近 6 年前
This is interesting, but I think it doesn&#x27;t necessarily fit the language well.<p>1. Go has very few keywords relative to other newish languages like Swift and Kotlin. Introducing a new one should only be done if the benefits are undeniable.<p>2. It causes an early return without any use of the &quot;return&quot; keyword, which feels pretty weird.<p>3. It&#x27;s a bit weird that err will be magically defined in a defer function if the surrounding function includes a &quot;try&quot;. Does err have to be declared earlier in the function? If yes, it&#x27;s strange that it seemingly never gets assigned. If there are multiple variables of type error in the function which one gets assigned the result of &quot;try&quot;?<p>4. Probably most importantly it doesn&#x27;t feel very explicit. In some languages this may not be a problem, but Go is designed to be very explicit and this seems a bit incongruous with the rest the language&#x27;s style.<p>Maybe I&#x27;m just not understanding the proposal. I do like how concise this is. It&#x27;s nicely backwards compatible and allows existing error handling to stay the same.
评论 #20103082 未加载
评论 #20102340 未加载
pcwalton将近 6 年前
It&#x27;s the try! macro from Rust! Obviously I&#x27;m a big fan of this style of error handling, and I&#x27;m happy to see it proposed for Go.
评论 #20102576 未加载
评论 #20101273 未加载
alexhutcheson将近 6 年前
It looks like it’s basically a less hacky version of what the RETURN_IF_ERROR and ASSIGN_OR_RETURN macros[1] do in C++.<p>From experience, those work pretty well. That approach eliminates a lot of the boilerplate bookkeeping code, while still making it explicitly obvious to the reader that a given function call can fail.<p>This seems nice, and I would definitely use it.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;protocolbuffers&#x2F;protobuf&#x2F;blob&#x2F;master&#x2F;src&#x2F;google&#x2F;protobuf&#x2F;stubs&#x2F;status_macros.h" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;protocolbuffers&#x2F;protobuf&#x2F;blob&#x2F;master&#x2F;src&#x2F;...</a>
codr7将近 6 年前
I get that the error is still propagated &quot;manually&quot; behind the scene; but how is this different from exceptions in practice once you use try everywhere (except where you forgot and the error is dropped silently)?<p>Here is my proposal: add restarts [0] as a complement to manual propagation.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;codr7&#x2F;g-fu&#x2F;blob&#x2F;master&#x2F;v1&#x2F;doc&#x2F;typical_restarts.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;codr7&#x2F;g-fu&#x2F;blob&#x2F;master&#x2F;v1&#x2F;doc&#x2F;typical_res...</a>
评论 #20101567 未加载
评论 #20101524 未加载
评论 #20102144 未加载
评论 #20102898 未加载
hliyan将近 6 年前
So basically they&#x27;re proposing:<p><pre><code> f, err := os.Open(filename) if err != nil { return …, err &#x2F;&#x2F; zero values for other results, if any } </code></pre> can be simplified to<p><pre><code> f := try(os.Open(filename)) </code></pre> This makes a lot of sense, but I&#x27;m of two minds. On one hand, it makes things much cleaner. On the other hand, it <i>might</i> be a first step onto a slippery slope that ends with exceptions.<p>A lot of others chiming in with different ideas on the original ticket: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;32437" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;32437</a>
评论 #20101197 未加载
评论 #20101339 未加载
评论 #20102188 未加载
评论 #20102308 未加载
评论 #20102910 未加载
评论 #20102517 未加载
bsaul将近 6 年前
I used to be a bit skeptical on the slow pace at which go decided to add new feature, and the insane care they took to have orthogonal features, but after seing the recent swift language evolution ( with google team pulling it toward dynamic features, and now apple adding weird and clumsy DSL support) i must say i’m now completely supporting their choice. taking a year before settling on a less ambitious but more orthogonal and minimalist feature is a sign of wisdom.<p>it is amazing the speed at which a language can go from something elegant to a mess.
cpuguy83将近 6 年前
Error handling is, to me, the most important thing when writing any code.<p>Promoting &quot;if err != nil { return }&quot; even more by giving it a keyword seems like a dangerous road to walk down.<p>Are we proposing solutions to make developers not have to type &quot;if err != nil&quot; or are we looking at how we can help developers handle errors better and be more productive?<p>I honestly don&#x27;t have anything to offer as far as ideas for changes to the language, but I really hope we think through the long-term ramifications of these changes.
评论 #20101763 未加载
stepforward将近 6 年前
If there are multiples `try` inside a single function, and we are debugging and want to know which call raises error, how can we do that?<p>Should `try` wraps the error and adds something more useful for debugging purpose? (the line number probably?)
评论 #20102510 未加载
评论 #20102016 未加载
dickeytk将近 6 年前
is it just me or does the word &quot;try&quot; seem to imply the opposite here? To me saying &quot;try&quot; is like saying &quot;attempt to run this&quot; like we have in a try&#x2F;catch block. I feel like something like &quot;expect&quot; would more directly explain what this does.<p>Great functionality though. I&#x27;d be very happy to see this included no matter what it&#x27;s named.<p>EDIT: This is answered in the FAQ section after I read further. Apparently it&#x27;s because &quot;try&quot; is already a keyword. I still don&#x27;t like it, but I get it.
评论 #20102504 未加载
jopsen将近 6 年前
I suspect the downside is that it&#x27;ll promote blind propagation of errors.<p>In rust that&#x27;s fine because the type system will document what error types can be returned.<p>In golang, it important that every error type that can be returned is manually documented. Otherwise, it&#x27;s better to just panic, since nobody can handle unknown errors anyways..<p>Or am I missing something?
评论 #20102234 未加载
marcrosoft将近 6 年前
Please for the love of god no.<p>Go is awesome for its simplicity. Errors should not be abstracted out of handling convenience. Errors are just values either eliminate the need for the error or handle it like you would any other value.<p>Stop trying to make go work like every other language.
评论 #20101423 未加载
评论 #20102722 未加载
评论 #20102174 未加载
leni536将近 6 年前
Interestingly enough C++ has a recent proposal that converges to a similar design from the other direction (i.e. exceptions).<p><a href="http:&#x2F;&#x2F;www.open-std.org&#x2F;jtc1&#x2F;sc22&#x2F;wg21&#x2F;docs&#x2F;papers&#x2F;2018&#x2F;p0709r2.pdf" rel="nofollow">http:&#x2F;&#x2F;www.open-std.org&#x2F;jtc1&#x2F;sc22&#x2F;wg21&#x2F;docs&#x2F;papers&#x2F;2018&#x2F;p070...</a><p>It&#x27;s still a lot more implicit than go&#x27;s design, as it&#x27;s meant to be compatible with regular exceptions.
Insanity将近 6 年前
I love Go, but error handling can become cumbersome. Though, I also think a lot of that feeling is because at the codebase I&#x27;m working on we return too many errors in a strange way.<p>We&#x27;re returning pointers almost everywhere along with an error, even simple methods that could do fine without. But the n you feel obligated to check them instead of ignore them, just in case someone does change the implementation of the simple function.<p>I feel like in some of the projects I wrote for myself, I use a lot less error handling and then I don&#x27;t mind the &#x27;if err != nil&#x27; approach anymore.<p>I&#x27;m sure this `try` keyword will help deal with the pain from the codebase I&#x27;m working on, though it doesn&#x27;t adress the root of our problem :(<p>To give an idea, in a function that does 5 other function calls, I need to check error returns 5 times. Every. Single. Line. That can&#x27;t be the norm, right? :P
评论 #20102408 未加载
cientifico将近 6 年前
The interesting part for me about the current form is that it makes me think what should be the state on the rest of the ecosystem in case an error happens. That extra lines, as for experience, pays off quite fast.<p>This form puts to the background that though, and I fear I feel tempted to put try everywhere.
评论 #20102457 未加载
airencracken将近 6 年前
Not a fan. I don&#x27;t mind the boilerplate to be honest.
icholy将近 6 年前
I think check&#x2F;handle is much better than this.
评论 #20103688 未加载
评论 #20102493 未加载
pjmlp将近 6 年前
Well, yet another magic function.
评论 #20102469 未加载
jy3将近 6 年前
Looks a lot like the already proposed check&#x2F;handle keywords that was met with a lot of push back from the Go community:<p><a href="https:&#x2F;&#x2F;go.googlesource.com&#x2F;proposal&#x2F;+&#x2F;master&#x2F;design&#x2F;go2draft-error-handling.md" rel="nofollow">https:&#x2F;&#x2F;go.googlesource.com&#x2F;proposal&#x2F;+&#x2F;master&#x2F;design&#x2F;go2draf...</a><p>Doesn&#x27;t look like the proposal adds anything new.
评论 #20102780 未加载
评论 #20102573 未加载
tapirl将近 6 年前
A little similar to this one, <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;yaxinlx&#x2F;1e013fec0e3c2469f97074dbf5d2e2c0" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;yaxinlx&#x2F;1e013fec0e3c2469f97074dbf5d2...</a>, but with more considerations for details.
gregwebs将近 6 年前
I hope the custom handler part is reconsidered. It is fine to 4 panic if the handler is nil or it returns nil.
ajcodez将近 6 年前
It’s contrary to Go core values of simplicity and avoiding slow patterns (using defer statements for error handling). It seems like a net loss and I would expect the proposal to be rejected.
panpanna将近 6 年前
Why not simply using a &quot;?&quot; the way kotlin and rust do?