It was also not clear if permitting an optional error handler would lead programmers to ignore proper error handling altogether. It would also be easy to do proper error handling everywhere but miss a single occurrence of a try. And so forth.

Having to pass an explicit nil makes it more difficult to forget to handle an error properly. You have to explicitly decide to not handle the error instead of doing so implicitly by leaving out an argument.

Thinking further about the conditional return briefly mentioned at https://github.com/golang/go/issues/32437#issuecomment-498947603.
It seems
return if f, err := os.Open("/my/file/path"); err != nil
would be more compliant with how Go's exising if looks.
If we add a rule for the return if statement that
when the last condition expression (like err != nil) is not present,
and the last variable of the declaration in the return if  statement is of the type error,
then the value of the last variable will be automatically compared with nil as the implicit condition.
Then the return if statement can be abbreviated into:
return if f, err := os.Open("my/file/path")
Which is very close to the signal-noise ratio that the try provides.
If we change the return if to try, it becomes
try f, err := os.Open("my/file/path")
It again becomes similar to other proposed variations of the try in this thread, at least syntactically.
Personally, I still prefer return if over try in this case because it makes the exit points of a function very explicit. For instance, when debugging I often highlight the keyword return within the editor to identify all exit points of a large function.
Unfortunately, it doesn't seem to help enough with the inconvenience of inserting debug logging either.
Unless we also allow a body block for return if, like
Original:
        return if f, err := os.Open("my/path")

When debugging:
-       return if f, err := os.Open("my/path")
+       return if f, err := os.Open("my/path") {
+               fmt.Printf("DEBUG: os.Open: %s\n", err)
+       }

The meaning of the body block of return if is obvious, I assume. It will be executed before defer and return.
That said, I don't have complaints with the existing error-handling approach in Go.

@velovix We quite liked the idea of a try with an explicit handler function as 2nd argument. But there were too many questions that didn't have obvious answers, as the design doc states. You have answered some of them in a way that seems reasonable to you. It's quite likely (and that was our experience inside the Go Team), that somebody else thinks the correct answer is quite a different one. For instance, you are stating that the handler argument should always be provided, but that it can be nil, to make it explicit we don't care about handling the error. Now what happens if one provides a function value (not a nil literal), and that function value (stored in a variable) happens to be nil? By analogy with the explicit nil value, no handling is required. Other might argue that this is a bug in the code. Or, alternatively one could allow it nil handler arguments, but then a function might inconsistently handler errors in some cases and not in others, and it's not necessarily obvious from the code, because it appears a handler is always present. Another argument was that it's better to have a top-level declaration of an error handler because that makes it very clear that the function does handle errors. Hence the defer. There's probably more.

It would be good to learn more about this concern. The current coding style using if statements to test for errors is about as explicit as it can be. It's very easy to add additional information to an error, on an individual basis (for each if). Often it makes sense to handle all errors detected in a function in a uniform way, which can be done with a defer - this is already possible now. It is the fact that we already have all the tools for good error handling in the language, and the problem of a handler construct not being orthogonal to defer, that led us to leave away a new mechanism solely for augmenting errors.

@griesemer - IIUC, you are saying that for callsite-dependent error contexts, the current if statement is fine. Whereas, this new try function is useful for the cases where handling multiple errors at a single place is useful.
I believe the concern was that, while simply doing a if err != nil { return err} may be fine for some cases, it is usually recommended to decorate the error before returning. And this proposal seems to address the previous and does not do much for the latter. Which essentially means folks will be encouraged to use easy-return pattern.

@agnivade You are correct, this proposal does exactly nothing to help with error decoration (but to recommend the use of defer). One reason is that language mechanisms for this already exist. As soon as error decoration is required, especially on an individual error basis, the additional amount of source text for the decoration code makes the if less onerous in comparison. It's the cases where no decoration is required, or where the decoration is always the same, where the boilerplate becomes a visible nuisance and then detracts from the important code.
Folks are already encouraged to use an easy-return pattern, try or no try, there's just less to write. Come to think of it, the only way to encourage error decoration is to make it mandatory, because no matter what language support is available, decorating errors will require more work.
One way to sweeten the deal would be to only permit something like try (or any analogous shortcutting notation) if an explicit (possibly empty) handler is provided somewhere (note that the original draft design didn't have such a requirement, either).
I'm not sure we want to go so far. Let me restate that plenty of perfectly fine code, say internals of a library, does not need to decorate errors everywhere. It's fine to just propagate errors up and decorate them just before they leave the API entry points, for instance. (In fact, decorating them everywhere will only lead to overdecorated errors that, with the real culprits hidden, make it harder to locate the important errors; very much like overly verbose logging can make it difficult to see what's really going on).

I think we can also add a catch function, which would be a nice pair, so:
func a() int {
  x := randInt()
  // let's assume that this is what recruiters should "fix" for us
  // or this happens in 3rd-party package.
  if x % 1337 != 0 {
    panic("not l33t enough")
  }
  return x
}

func b() error {
  // if a() panics, then x = 0, err = error{"not l33t enough"}
  x, err := catch(a())
  if err != nil {
    return err
  }
  sendSomewhereElse(x)
  return nil
}

// which could be simplified even further

func c() error {
  x := try(catch(a()))
  sendSomewhereElse(x)
  return nil
}

in this example, catch() would recover() a panic and return ..., panicValue.
of course, we have an obvious corner case in which we have a func, that also returns an error. in this case I think it would be convenient to just pass-thru error value.
so, basically, you can then use catch() to actually recover() panics and turn them into errors.
this looks quite funny for me, 'cause Go doesn't actually have exceptions, but in this case we have pretty neat try()-catch() pattern, that also shouldn't blow up your entire codebase with something like Java (catch(Throwable) in Main + throws LiterallyAnything). you can easily process someone's panics like those was usual errors. I've currently have about 6mln+ LoC in Go in my current project, and I think this would simplify things at least for me.

@griesemer Thanks for your recap of the discussion.
I notice one point is missing in there: some people have argued that we should wait with this feature until we have generics, which will hopefully allow us to solve this problem in a more elegant way.
Furthermore, I also like @velovix's suggestion, and while I appreciate that this raises a few questions as described in the spec, I think these can be easily answered in a reasonable way, as @velovix already did.
For example:

What happens if one provides a function value (not a nil literal), and that function value (stored in a variable) happens to be nil? => Do not handle the error, period. This is useful in case the error handling depends on context and the handler variable is set depending on whether or not error handling is required. It's not a bug, rather, it's a feature. :)

Another argument was that it's better to have a top-level declaration of an error handler because that makes it very clear that the function does handle errors. => So define the error handler at the top of the function as a named closure function and use that, so it's also very clear that the error should be handled. This is not a serious issue, more of a style requirement.

What other concerns were there? I am pretty sure they can be all be answered similarly in a reasonable way.
Finally,  as you say, "one way to sweeten the deal would be to only permit something like try (or any analogous shortcutting notation) if an explicit (possibly empty) handler is provided somewhere". I think that Iif we are to proceed with this proposal, we should actually take it "this far", to encourage proper, "explicit is better than implicit" error handling.

@griesemer

Now what happens if one provides a function value (not a nil literal), and that function value (stored in a variable) happens to be nil? By analogy with the explicit nil value, no handling is required. But others might argue that this is a bug in the code.

In theory this does seem like a potential gotcha, though I'm having a hard time conceptualizing a reasonable situation where a handler would end up being nil by accident. I imagine that handlers would most commonly either come from a utility function defined elsewhere, or as a closure defined in the function itself. Neither of these are likely to become nil unexpectedly. You could theoretically have a scenario where handler functions are being passed around as arguments to other functions, but to my eyes it seems rather far-fetched.

Another argument was that it's better to have a top-level declaration of an error handler because that makes it very clear that the function does handle errors. Hence the defer.

As @beoran mentioned, defining the handler as a closure near the top of the function would look very similar in style, and that's how I personally expect people would be using handlers most commonly. While I do appreciate the clarity won by the fact that all functions that handle errors will be using defer, it may become less clear when a function needs to pivot in its error handling strategy halfway down the function. Then, there will be two defers to look at and the reader will have to reason about how they will interact with each other. This is a situation where I believe a handler argument would be both more clear and ergonomic, and I do think that this will be a relatively common scenario.

Is it possible to make it work without brackets?
I.e. something like:
a := try func(some)

@Cyberax - As already mentioned above, it is very essential that you read the design doc carefully before posting. Since this is a high-traffic issue, with a lot of people subscribed.
The doc discusses operators vs functions in detail.

I like this a lot more than I liked august version.
I think that much of the negative feedback, that isn't outright opposed to returns without the return keyword, can be summarized in two points:

people don't like named result parameters, which would become required in most cases
it discourages adding detailed context to errors

See for example:

https://github.com/golang/go/issues/32437#issuecomment-498937169
https://github.com/golang/go/issues/32437#issuecomment-498967099
https://github.com/golang/go/issues/32437#issuecomment-499194787
https://github.com/golang/go/issues/32437#issuecomment-499309304

The rebuttal for those two objections is respectively:

"we decided that [named result parameters] were ok"
"No one is going to make you use try" / it's not going to be appropriate for 100% of cases

I don't really have anything to say about 1 (I don't feel strongly about it). But regarding 2 I'd note that the august proposal didn't have this problem, most counter proposals also don't have this problem.
In particular neither the tryf counter-proposal (that's been posted independently twice in this thread) nor the try(X, handlefn) counter-proposal (that was part of the design iterations) had this problem.
I think it's hard to argue that try, as it, is will push people away from decorating errors with relavant context and towards a single generic per-function error decoration.
Because of these reasons I think it's worth trying to address this issue and I want to propose a possible solution:

Currently the parameter of defer can only be a function or method call. Allow defer to also have a function name or a function literal, i.e.

defer func(...) {...}
defer packageName.functionName

When panic or deferreturn encounter this type of defer they will call the function passing the zero value for all their parameters

Allow try to have more than one parameter

When try encounters the new type of defer it will call the function passing a pointer to the error value as the first parameter followed by all of try's own parameters, except the first one.

For example, given:
func errorfn() error {
	return errors.New("an error")
}

func f(fail bool) {
	defer func(err *error, a, b, c int) {
		fmt.Printf("a=%d b=%d c=%d\n", a, b, c)
	}
	if fail {
		try(errorfn, 1, 2, 3)
	}
}

the following will happen:
f(false)		// prints "a=0 b=0 c=0"
f(true)			// prints "a=1 b=2 c=3"

The code in https://github.com/golang/go/issues/32437#issuecomment-499309304 by @zeebo could then be rewritten as:
func (c *Config) Build() error {
	defer func(err *error, msg string, args ...interface{}) {
		if *err == nil || msg == "" {
			return
		}
		*err = errors.WithMessagef(err, msg, args...)
	}
	pkgPath := try(c.load(), "load config dir")

	b := bytes.NewBuffer(nil)
	try(templates.ExecuteTemplate(b, "main", c), "execute main template")

	buf := try(format.Source(b.Bytes()), "format main template")

	target := fmt.Sprintf("%s.go", filename(pkgPath))
	try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)
	// ...
}

And defining ErrorHandlef as:
func HandleErrorf(err *error, format string, args ...interface{}) {
        if *err != nil && format != "" {
                *err = fmt.Errorf(format + ": %v", append(args, *err)...)
        }
}

would give everyone the much sought after tryf for free, without pulling fmt-style format strings into the core language.
This feature is backwards compatible because defer doesn't allow function expressions as its argument. It doesn't introduce new keywords.
The changes that need to be made to implement it, in addition to the ones outlined in https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md, are:

teach parser about the new kind of defer
change the type checker to check that inside a function all the defers that have a function as parameter (instead of a call) also have the same signature
change the type checker to check that the parameters passed to try match the signature of the functions passed to defer
change the backend (?) to generate the appropriate deferproc call
change the implementation of try to copy its arguments into the arguments of the deferred call when it encounters a call deferred by the new kind of defer.

After the complexities of the check/handle draft design, I was pleasantly surprised to see this much simpler and pragmatic proposal land though I'm disappointed that there has been so much push-back against it.
Admittedly a lot of the push-back is coming from people who are quite happy with the present verbosity (a perfectly reasonable position to take) and who presumably wouldn't really welcome any proposal to alleviate it. For the rest of us, I think this proposal hits the sweet spot of being simple and Go-like, not trying to do too much and dove-tailing well with the existing error handling techniques on which you could always fall back if try didn't do exactly what you wanted.
Regarding some specific points:

The only thing I dislike about the proposal is the need to have a named error return parameter when defer is used but, having said that, I can't think of any other solution which wouldn't be at odds with the way the rest of the language works. So I think we will just have to accept this if the proposal is adopted.

It's a pity that try doesn't play well with the testing package for functions which don't return an error value. My own preferred solution to this would be to have a second built-in function (perhaps ptry or must) which always panicked rather than returned on encountering a non-nil error and which could therefore be used with the aforementioned functions (including main). Although this idea has been rejected in the present iteration of the proposal, I formed the impression it was a 'close call' and it may therefore be eligible for reconsideration.

I think it would be difficult for folks to get their heads around what go try(f) or defer try(f) were doing and that it's best therefore to just prohibit them altogether.

I agree with those who think that the existing error handling techniques would look less verbose if go fmt didn't rewrite single line if statements. Personally, I would prefer a simple rule that this would be allowed for any single statement if whether concerned with error handling or not. In fact I have never been able to understand why this isn't currently allowed when writing single-line functions where the body is placed on the same line as the declaration is allowed.

In the case decorating errors
func myfunc()( err error){
try(thing())
defer func(){
err = errors.Wrap(err,"more context")
}()
}

This feels considerably more verbose  and painful than the existing paradigms, and not as concise as check/handle. The non-wrapping try() variant is more concise, but it feels like people will end up using a mix of try, and plain error returns.  I'm not sure I like the idea of mixing try and simple error returns, but I'm totally sold on decorating errors (and looking forward to Is/As). Make me think that whilst this is syntactically neat, I'm not sure I would want to actually use it. check/handle felt something I would more thoroughly embrace.

I really like the simplicity of this and the "do one thing well" approach. In my GoAWK interpreter it would be very helpful -- I have about 100 if err != nil { return nil } constructs that it would simplify and tidy up, and that's in a fairly small codebase.
I've read the proposal's justification for making it a builtin rather than a keyword, and it boils down to not having to adjust the parser. But isn't that a relatively small amount of pain for compiler and tooling writers, whereas having the extra parens and the this-looks-like-a-function-but-isn't readability issues will be something all Go coders and code-readers have to endure. In my opinion the argument (excuse? :-) that "but panic() does control flow" doesn't cut it, because panic and recover are by their very nature, exceptional, whereas try() will be normal error handling and control flow.
I'd definitely appreciate it even if this went in as is, but my strong preference would be for normal control flow to be clear, i.e., done via a keyword.

I'm in favour of this proposal. It avoids my largest reservation about the previous proposal: the non-orthogonality of handle with respect to defer.
I'd like to mention two aspects that I don't think have been highlighted above.
Firstly, although this proposal doesn't make it easy to add context-specific error text to an error, it does make it easy to add stack frame error-tracing information to an error: https://play.golang.org/p/YL1MoqR08E6
Secondly, try is arguably a fair solution to most of the problems underlying https://github.com/golang/go/issues/19642. To take an example from that issue, you could use try to avoid writing out all the return values each time. This is also potentially useful when returning by-value struct types with long names.
func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
	xx := int(x)
	if f.NumGlyphs() <= xx {
		try(ErrNotFound)
	}
	i := f.cached.locations[xx+0]
	j := f.cached.locations[xx+1]
	if j < i {
		try(errInvalidGlyphDataLength)
	}
	if j-i > maxGlyphDataLength {
		try(errUnsupportedGlyphDataLength)
	}
	buf, err = b.view(&f.src, int(i), int(j-i))
	return buf, i, j - i, err
}

I like this proposal also.
And I have a request.
Like make, can we allow try to take a variable number of parameters

try(f):
as above.
a return error value is mandatory (as the last return parameter).
MOST COMMON USAGE MODEL
try(f, doPanic bool):
as above, but if doPanic, then panic(err) instead of returning.
In this mode, a return error value is not necessary.
try(f, fn):
as above, but call fn(err) before returning.
In this mode, a return error value is not necessary.

This way, it is one builtin that can handle all use-cases, while still being explicit. Its advantages:

always explicit - no need to infer whether to panic or set error and return
supports context-specific handler (but no handler chain)
supports use-cases where there is no error return variable
supports must(...) semantics

While repetitiveif err !=nil { return ... err } is certainly an ugly stutter, I'm with those
who think the try() proposal is very low on readability and somewhat inexplicit.
The use of named returns is problematic too.
If this sort of tidying is needed, why not try(err) as syntactic sugar for
if err !=nil { return err }:
file, err := os.Open("file.go")
try(err)

for
file, err := os.Open("file.go")
if err != nil {
   return err
}

And if there is more than one return value, try(err) could return t1, ... tn, err
where t1, ... tn are the zero values of the other return values.
This suggestion would obviate the need for named return values and be,
in my view, more readable.
Even better, I think would be:
file, try(err) := os.Open("file.go")
Or even
file, err? := os.Open("file.go")
This last is backwards compatible (? is currently not allowed in identifiers).
(This suggestion is related to https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes. But the recurring theme examples seem different because that was at a stage when an explicit handle was still being discussed instead of leaving that to a defer.)
Thanks to the go team for this serious, interesting proposal.

@rogpeppe comment if try auto-adds the stack frame, not me, I'm ok with it discouraging adding context.

@aarzilli - So according to your proposal, is a defer clause mandatory every time we give extra parameters to tryf ?
What happens if I do
try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

and do not write a defer function ?

@agnivade

What happens if I do (...) and do not write a defer function ?

typecheck error.

In my opinion, using try to avoid writing out all the return values is actually just another strike against it.
func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
	xx := int(x)
	if f.NumGlyphs() <= xx {
		try(ErrNotFound)
	}
	//...

I completely understand the desire to avoid having to write out return nil, 0, 0, ErrNotFound, but I would much rather solve that some other way.
The word try doesn't mean "return".  And that's how it's being used here.  I would actually prefer that the proposal change so that try can't take an error value directly, because I don't ever want anyone writing code like that ^^ .  It reads wrong.  If you showed that code to a newbie, they'd have no clue what that try was doing.
If we want a way to easily just return defaults and an error value, let's solve that separately. Maybe another builtin like
return default(ErrNotFound)

At least that reads with some kind of logic.
But let's not abuse try to solve some other problem.

@natefinch if the try builtin is named check like in the original proposal, it would be check(err) which reads considerably better, imo.
Putting that aside, I don't know if it's really an abuse to write try(err). It falls out of the definition cleanly. But, on the other hand, that also means that this is legal:
a, b := try(1, f(), err)

I guess my main problem with try is that it's really just a panic that only goes up one level... except that unlike panic, it's an expression, not a statement, so you can hide it in the middle of a statement somewhere. That almost makes it worse than panic.

@natefinch If you conceptualize it like a panic that goes up one level and then does other things, it seems pretty messy. However, I conceptualize it differently. Functions that return errors in Go are effectively returning a Result<T, error>, to loosely borrow from Rust's terminology. try is a utility that unpacks the result and either returns an "error result" if error != nil, or unpacks the T portion of the result if error == nil.
Of course, in Go we don't actually have result objects, but it's effectively the same pattern and try seems like a natural codification of that pattern. I believe that any solution to this problem is going to have to codify some aspect of error handling, and trys take on it seems reasonable to me. Myself and others are suggesting to extend the capability of try a bit to better fit existing Go error handling patterns, but the underlying concept remains the same.

@ugorji The try(f, bool) variant you propose sounds like the must from #32219.

@ugorji The try(f, bool) variant you propose sounds like the must from #32219.

Yes, it is. I just felt like they all 3 cases could be handled with a singular builtin function, and satisfy all use-cases elegantly.

Since try() is already magical, and aware of the error return value, could it be augmented to also return a pointer to that value in when called in the nullary (zero argument) form? That would eliminate the need for named returns, and I believe, help to visually correlate where the error is expected to come from in defer statements. For example:
func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

I think the boolean on try(f, bool) would make it hard to read and easy to miss. I like your proposal but for the panic case I think that that could be left out for users to write that inside the handler from your third bullet, e.g. try(f(), func(err error) { panic('at the disco'); }), this makes it more explicit for users than a hidden try(f(), true) that is easy to overlook, and I don't think the builtin functions should encourage panics.

@ugorji
I think the boolean on try(f, bool) would make it hard to read and easy to miss. I like your proposal but for the panic case I think that that could be left out for users to write that inside the handler from your third bullet, e.g. try(f(), func(err error) { panic('at the disco'); }), this makes it more explicit for users than a hidden try(f(), true) that is easy to overlook, and I don't think the builtin functions should encourage panics.

On further thought, I tend to agree with your position and your reasoning, and it still looks elegant as a one-liner.

@patrick-nyt is still another proponent of assignment syntax to trigger a nil test, in https://github.com/golang/go/issues/32437#issuecomment-499533464
This concept appears in 13 separate responses to the check/handle proposal
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes
Why? Because it reads like Go 1, whereas try() and check do not.

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md#draft-design

One objection to try seems to be that it is an expression. Suppose instead that there is a unary postfix statement ? that means return if not nil. Here is the standard code sample (assuming that my proposed deferred package is added):
func CopyFile(src, dst string) error {
    var err error // Don't need a named return because err is explicitly named
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r, err := os.Open(src)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    w, err := os.Create(dst)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    _, err = io.Copy(w, r)

    return err
}

The pgStore example:
func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    err?

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    // tricky bit: this would not change the value of err
    // but the deferred.Cond would still be triggered by err being set before
    deferred.Format(err, "insert table")?

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    deferred.Format(err, "insert table2")?

    return tx.Commit()
}

I like this from @jargv:

Since try() is already magical, and aware of the error return value, could it be augmented to also return a pointer to that value in when called in the nullary (zero argument) form? That would eliminate the need for named returns

But instead of overloading the name try based on the number of args, I think there could be another magic builtin, say reterr or something.

I have briefed through some very often used packages, looking for go code that "suffers" from err handling but must have been well thought before written, trying to figure out what "magic" would the proposed try() would do.
Currently, unless I misunderstood the proposal, many of those (e.g. not super basic error handling) would not gain much, or would have to stay with the "old" error handling style.
Example from net/http/request.go:
`func (r *Request) write(w io.Writer, usingProxy bool, extraHeaders Header, waitForContinue func() bool) (err error) {
trace := httptrace.ContextClientTrace(r.Context())
if trace != nil && trace.WroteRequest != nil {
defer func() {
trace.WroteRequest(httptrace.WroteRequestInfo{
Err: err,
})
}()
}
// Find the target host. Prefer the Host: header, but if that
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
host := cleanHost(r.Host)
if host == "" {
	if r.URL == nil {
		return errMissingHost
	}
	host = cleanHost(r.URL.Host)
}

// According to RFC 6874, an HTTP client, proxy, or other
// intermediary must remove any IPv6 zone identifier attached
// to an outgoing URI.
host = removeZone(host)

ruri := r.URL.RequestURI()
if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
	ruri = r.URL.Scheme + "://" + host + ruri
} else if r.Method == "CONNECT" && r.URL.Path == "" {
	// CONNECT requests normally give just the host and port, not a full URL.
	ruri = host
	if r.URL.Opaque != "" {
		ruri = r.URL.Opaque
	}
}
if stringContainsCTLByte(ruri) {
	return errors.New("net/http: can't write control character in Request.URL")
}
// TODO: validate r.Method too? At least it's less likely to
// come from an attacker (more likely to be a constant in
// code).

// Wrap the writer in a bufio Writer if it's not already buffered.
// Don't always call NewWriter, as that forces a bytes.Buffer
// and other small bufio Writers to have a minimum 4k buffer
// size.
var bw *bufio.Writer
if _, ok := w.(io.ByteWriter); !ok {
	bw = bufio.NewWriter(w)
	w = bw
}

_, err = fmt.Fprintf(w, "%s %s HTTP/1.1\r\n", valueOrDefault(r.Method, "GET"), ruri)
if err != nil {
	return err
}

// Header lines
_, err = fmt.Fprintf(w, "Host: %s\r\n", host)
if err != nil {
	return err
}
if trace != nil && trace.WroteHeaderField != nil {
	trace.WroteHeaderField("Host", []string{host})
}

// Use the defaultUserAgent unless the Header contains one, which
// may be blank to not send the header.
userAgent := defaultUserAgent
if r.Header.has("User-Agent") {
	userAgent = r.Header.Get("User-Agent")
}
if userAgent != "" {
	_, err = fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)
	if err != nil {
		return err
	}
	if trace != nil && trace.WroteHeaderField != nil {
		trace.WroteHeaderField("User-Agent", []string{userAgent})
	}
}

// Process Body,ContentLength,Close,Trailer
tw, err := newTransferWriter(r)
if err != nil {
	return err
}
err = tw.writeHeader(w, trace)
if err != nil {
	return err
}

err = r.Header.writeSubset(w, reqWriteExcludeHeader, trace)
if err != nil {
	return err
}

if extraHeaders != nil {
	err = extraHeaders.write(w, trace)
	if err != nil {
		return err
	}
}

_, err = io.WriteString(w, "\r\n")
if err != nil {
	return err
}

if trace != nil && trace.WroteHeaders != nil {
	trace.WroteHeaders()
}

// Flush and wait for 100-continue if expected.
if waitForContinue != nil {
	if bw, ok := w.(*bufio.Writer); ok {
		err = bw.Flush()
		if err != nil {
			return err
		}
	}
	if trace != nil && trace.Wait100Continue != nil {
		trace.Wait100Continue()
	}
	if !waitForContinue() {
		r.closeBody()
		return nil
	}
}

if bw, ok := w.(*bufio.Writer); ok && tw.FlushHeaders {
	if err := bw.Flush(); err != nil {
		return err
	}
}

// Write body and trailer
err = tw.writeBody(w)
if err != nil {
	if tw.bodyReadError == err {
		err = requestBodyReadError{err}
	}
	return err
}

if bw != nil {
	return bw.Flush()
}
return nil

}
`
or as used in a thorough test such as pprof/profile/profile_test.go:
`func checkAggregation(prof *Profile, a *aggTest) error {
// Check that the total number of samples for the rows was preserved.
total := int64(0)
samples := make(map[string]bool)
for _, sample := range prof.Sample {
	tb := locationHash(sample)
	samples[tb] = true
	total += sample.Value[0]
}

if total != totalSamples {
	return fmt.Errorf("sample total %d, want %d", total, totalSamples)
}

// Check the number of unique sample locations
if a.rows != len(samples) {
	return fmt.Errorf("number of samples %d, want %d", len(samples), a.rows)
}

// Check that all mappings have the right detail flags.
for _, m := range prof.Mapping {
	if m.HasFunctions != a.function {
		return fmt.Errorf("unexpected mapping.HasFunctions %v, want %v", m.HasFunctions, a.function)
	}
	if m.HasFilenames != a.fileline {
		return fmt.Errorf("unexpected mapping.HasFilenames %v, want %v", m.HasFilenames, a.fileline)
	}
	if m.HasLineNumbers != a.fileline {
		return fmt.Errorf("unexpected mapping.HasLineNumbers %v, want %v", m.HasLineNumbers, a.fileline)
	}
	if m.HasInlineFrames != a.inlineFrame {
		return fmt.Errorf("unexpected mapping.HasInlineFrames %v, want %v", m.HasInlineFrames, a.inlineFrame)
	}
}

// Check that aggregation has removed finer resolution data.
for _, l := range prof.Location {
	if !a.inlineFrame && len(l.Line) > 1 {
		return fmt.Errorf("found %d lines on location %d, want 1", len(l.Line), l.ID)
	}

	for _, ln := range l.Line {
		if !a.fileline && (ln.Function.Filename != "" || ln.Line != 0) {
			return fmt.Errorf("found line %s:%d on location %d, want :0",
				ln.Function.Filename, ln.Line, l.ID)
		}
		if !a.function && (ln.Function.Name != "") {
			return fmt.Errorf(`found file %s location %d, want ""`,
				ln.Function.Name, l.ID)
		}
	}
}

return nil

}
`
These are two examples I can think of in which one would say : "I would like a better error handling option"
Can someone demonstrate how would these improve using try() ?

I'm mostly in favor of this proposal.
My main concern, shared with many commenters, is about named result parameters. The current proposal certainly encourages much more use of named result parameters and I think that would be a mistake. I don't believe this is simply a matter of style as the proposal states: named results are a subtle feature of the language which, in many cases, makes the code more bug-prone or less clear. After ~8 years of reading and writing Go code, I really only use named result parameters for two purposes:

Documentation of result parameters
Manipulating a result value (usually an error) inside a defer

To attack this issue from a new direction, here's a an idea which I don't think closely aligns with anything that has been discussed in the design document or this issue comment thread. Let's call it "error-defers":
Allow defer to be used to call functions with an implicit error parameter.
So if you have a function
func f(err error, t1 T1, t2 T2, ..., tn Tn) error

Then, in a function g where the last result parameter has type error (i.e., any function where try my be used), a call to f may be deferred as follows:
func g() (R0, R0, ..., error) {
	defer f(t0, t1, ..., tn) // err is implicit
}

The semantics of error-defer are:

The deferred call to f is called with the last result parameter of g as the first input parameter of f
f is only called if that error is not nil
The result of f is assigned to the last result parameter of g

So to use an example from the old error-handling design doc, using error-defer and try, we could do
func printSum(a, b string) error {
	defer func(err error) error {
		return fmt.Errorf("printSum(%q + %q): %v", a, b, err)
	}()
	x := try(strconv.Atoi(a))
	y := try(strconv.Atoi(b))
	fmt.Println("result:", x+y)
	return nil
}

Here's how HandleErrorf would work:
func printSum(a, b string) error {
	defer handleErrorf("printSum(%q + %q)", a, b)
	x := try(strconv.Atoi(a))
	y := try(strconv.Atoi(b))
	fmt.Println("result:", x+y)
	return nil
}

func handleErrorf(err error, format string, args ...interface{}) error {
	return fmt.Errorf(format+": %v", append(args, err)...)
}

One corner case that would need to be worked out is how to handle cases where it's ambiguous which form of defer we are using. I think that only happens with (very unusual) functions with signatures like this:
func(error, ...error) error

It seems reasonable to say that this case is handled in the non-error-defer way (and this preserves backward compatibility).

Thinking about this idea for the last couple of days, it is a little bit magical, but the avoidance of named result parameters is a large advantage in its favor. Since try encourages more use of defer for error manipulation, it makes some sense that defer could be extended to better suit it to that purpose. Also, there's a certain symmetry between try and error-defer.
Finally, error-defers are useful today even without try, since they supplant the use of named result parameters for manipulating error returns. For example, here's an edited version of some real code:
// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) (_ []*File, err error) {
	files := make([]*file, len(keys))

	defer func() {
		if err != nil {
			// Return any successfully retrieved files.
			for _, f := range files {
				if f != nil {
					c.put(f)
				}
			}
		}
	}()

	// ...
}

With error-defer, this becomes:
// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) ([]*File, error) {
	files := make([]*file, len(keys))

	defer func(err error) error {
		// Return any successfully retrieved files.
		for _, f := range files {
			if f != nil {
				c.put(f)
			}
		}
		return err
	}()

	// ...
}

@beoran Regarding your comment that we should wait for generics. Generics won't help here - please read the FAQ.
Regarding your suggestions on @velovix 's 2-argument try's default behavior: As I said before, your idea of what is the obviously reasonable choice is somebody else's nightmare.
May I suggest that we continue this discussion once a wide consensus evolves that try with an explicit error handler is a better idea than the current minimal try. At that point it makes sense to discuss the fine points of such a design.
(I do like having a handler, for that matter. It's one of our earlier proposals. And if we adopt try as is, we still can move towards a try with a handler in a forward-compatible way - at least if the handler is optional. But let's take one step at a time.)

@aarzilli Thanks for your suggestion.
As long as decorating errors is optional, people will lean towards not doing it (it's extra work after all). See also my comment here.
So, I don't think the proposed try discourages people from decorating errors (they are already discouraged even with the if for the above reason); it's that try doesn't encourage it.
(One way of encouraging it is to tie it into try: One can only use try if one also decorates the error, or explicitly opts out.)
But back to your suggestions: I think you're introducing a whole lot more machinery here. Changing the semantics of defer just to make it work better for try is not something we would want to consider unless those defer changes are beneficial in a more general way. Also, your suggestion ties defer together with try and thus makes both those mechanisms less orthogonal; something we wouldn't want to avoid.
But more importantly, I doubt you would want to force everybody to write a defer just so they can use try. But without doing that, we're back to square one: people will lean towards not decorating errors.

(I do like having a handler, for that matter. It's one of our earlier proposals. And if we adopt try as is, we still can move towards a try with a handler in a forward-compatible way - at least if the handler is optional. But let's take one step at a time.)

Sure, perhaps a multi-step approach is the way to go. If we add an optional handler argument in the future, tooling could be created to warn the writer of an unhandled try in the same spirit as the errcheck tool. Regardless, I appreciate your feedback!

@alanfo Thanks for your positive feedback.
Regarding the points you brought up:

If the only issue with try is the fact that one will have to name an error return so we can decorate an error via defer, I think we are good. If naming the result turns out to be a real issue, we could address it. A simple mechanism I can think of would be a predeclared variable that is an alias to an error result (think of it as holding the error which triggered the most recent try). There may be better ideas. We didn't propose this because there is already a mechanism in the language, which is to name the result.
try and testing: This can be addressed and made to work. See the detailed doc.
This is explicitly addressed in the detailed doc.
Acknowledged.

@benhoyt Thanks for your positive feedback.
If the main argument against this proposal is the fact that try is a built-in, we're in a great spot. Using a built-in is simply a pragmatic solution for the backward-compatibility problem (it happens to cause no extra work for the parser, and tools etc. - but that's just a nice side benefit, not the primary reason). There are also some benefits to having to write parentheses, this is discussed in detail in the design doc (section on Properties of the proposed design).
All that said, if using a built-in is the showstopper, we should consider the try keyword. It will not be backward-compatible though with existing code as the keyword may conflict with existing identifiers.
(To be complete, there's also the option of an operator such as ?, which would be backward-compatible. It doesn't strike me as the best choice for a language such as Go, though. But again, if that's all it takes to make try palatable, we should perhaps consider it.)

@ugorji Thanks for your positive feedback.
try could be extended to take an additional argument. Our preference would be to take only a function with signature func (error) error. If you want to panic, it's easy to provide a one-line helper function:
func doPanic(err error) error { panic(err) }

Better to keep the design of try simple.

@patrick-nyt What you are suggesting:
file, err := os.Open("file.go")
try(err)

will be possible with the current proposal.

@dpinela , @ugorji Please read also the design doc on the subject of must vs try. It's better to keep try as simple as possible. must is a common "pattern" in initialization expressions, but there's no urgent need to "fix" that.

@jargv Thanks for your suggestion. This is an interesting idea (see also my comment here on this subject). To summarize:

try(x) operates as proposed
try() returns an *error pointing to the error result

This would be indeed another way to get to the result w/o having to name it.

@cespare The suggestion by @jargv looks much simpler to me than what you are proposing. It solves the same problem of access to the result error. What do you think?

Asper https://github.com/golang/go/issues/32437#issuecomment-499320588:

func doPanic(err error) error { panic(err) }

I anticipate this function would be quite common. Could this be predefined in "builtin"?

Too bad that you do not anticipate generics powerful enough to implement
try, I actually would have hoped it would be possible to do so.
Yes, this proposal could be a first step, although I don't see much use in
it myself as it stands now.
Granted, this issue has perhaps too much focus on detailed alternatives,
but it goes to show that many participants are not completely happy with
it. What seems to be lacking is a wide consensus about this proposal...
Op vr 7 jun. 2019 01:04 schreef pj<EMAIL_ADDRESS>
Asper #32437 (comment)
https://github.com/golang/go/issues/32437#issuecomment-499320588:
func doPanic(err error) error { panic(err) }
I anticipate this function would be quite common. Could this be predefined
in "builtin"?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEMYZY#issuecomment-499698791,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

@pjebs, I’ve written the equivalent function dozens of times. I usually call it “orDie” or “check”. It’s so simple, there’s no real need to make it part of the standard library. Plus different people may want logging or whatever before termination.

@beoran Perhaps you could expand on the connection between generics and error handling.  When I think about them, they seem like two different things.  Generics is not a catch all that can address all problems with the language.  It is the ability to write a single function that can operate on multiple types.
This specific error handling proposal tries to reduce boilerplate by introducing a predeclared function try that changes the flow control in some circumstances.  Generics will never change the flow of control.  So I really don't see the relationship.

My initial reaction to this was a 👎 as I imagined that handling several error prone calls within a function would make the defer error handle confusing. After reading through the whole proposal, I have flipped my reaction to a ❤ and 👍 as I learnt that this can still be achieved with relatively low complexity.

@carlmjohnson Yes it is simple.
The advantages of a predeclared function is:

We can one-line it
We don't need to redeclare the err => die function in every package we use or maintain a common location for it. Since it's common to probably everyone in Go community, probably the "standard package" is the common location for it.

@griesemer With the error-handler variant of original try proposal, is the overarching function's requirement for returning error now no longer required.
When I first enquired about it the err => panic, I was pointed out that the proposal considered it but considered it too dangerous. But if we make the use of try() without a error-handler in a scenario where overarching function doesn't return error, making it into a compile-time error alleviates the concern discussed in the proposal

@pjebs The overarching function's requirement for returning an error was not required in the original design if an error handler was provided. But it's just another complication of try. It is much better to keep it simple. Instead, it would be clearer to have a separate must function, which always panics on error (but otherwise is like try). Then it's obvious what happens in the code and one doesn't have look at the context.
The main attraction of having such a must would be that it could be used with unit tests; especially if the testing package were suitably adjusted to recover from the panics caused by must and report them as test failures in a nice way. But why add yet another new language mechanism when we can just adjust the testing package to also accept test function of the form TestXxx(t *testing.T) error? If they return an error, which seems quite natural after all (we should have done this from the start), then try will work just fine. Local tests will need a bit more work, but it's probably doable.
The other relatively common use for must is in global initialization expressions (must(regexp.Compile..., etc.). If would a "nice to have" but that does not rise it to the level required for a new language feature.

@griesemer Given that must is vaguely related to try, and given that the momentum is towards try getting implemented, don't you think it's good to consider must at the same time - even if it's merely a "nice to have".
The chances are that if it's not discussed in this round, it simply won't get implemented at least for 3+ years. The overlap in discussion would also be good rather than starting from scratch and recycling discussions.

@pjebs It certainly doesn't appear that there's any "momentum towards try getting implemented" right now... - And we also only just posted this two days ago. Nor has anything been decided. Let's give this some time.
It has not escaped us that must dovetails nicely with try, but that's not the same as making it part of the language. We only have started to explore this space with a wider group of people. We really don't know yet what might come up in support or against it. Thanks.

After spending hours reading all the comments and the detailed design doc I wanted to add my views to this proposal.
I will do my best to respect @ianlancetaylor's request not to just restate previous points but to instead add new comments to the discussion. However I don't think I can make the new comments without somewhat referencing prior comments.
Concerns
Unfortunate overloading of defer
The preference to overload the obvious and straightforward nature of defer as alarming. If I write defer closeFile(f) that is straightforward and obvious to me what is happening and why; at the end of the func that will be called. And while using defer for panic() and recover() is less obvious, I rarely if ever use it and almost never see it when reading other's code.
Spoo to overload defer to also handle errors is not obvious and confusing. Why the keyword defer? Does defer not mean "Do later" instead of "Maybe to later?"
Also there is the concern mentioned by the Go team about defer performance. Given that, it seems doubly unfortunate that defer is being considered for the "hot path" code flow.
No stats verifying a significant use-case
As @prologic mentioned, is this try() proposal predicated on a large percentage of code that would use this use-case, or is it instead based on attempting to placate those who have complained about Go error handling?
I wish I knew how to give you stats from my code base without exhaustively reviewing every file and take notes; I don't know how @prologic was able to though glad he did.
But anecdotally I would be surprised if try() addressed 5% of my use-cases and would suspect that it would address less than 1%. Do you know for certain that others have vastly different results?  Have you taken a subset of the standard library and tried to see how it would be applied?
Because without known stats that this is appropriate to a large chuck of code in the wild I have to ask is this new complicating change to the language that will require everyone to learn the new concepts really address a compelling number of use-cases?
Makes it easier for developers to ignore errors
This is a total repeat of what others have comments, but what basically providing try() is analogous in many ways to simply embracing the following as idomatic code, and this is code that will never find its way into any code any self-respecting developer ships:
f, _ := os.Open(filename)

I know I can be better in my own code, but I also know many of us depend on the largess of other Go developers who publish some tremendously useful packages, but from what I have seen in "Other People's Code(tm)" best practices in error handling is often ignored.
So seriously, do we really want to make it easier for developers to ignore errors and allow them to polute GitHub with non-robust packages?
Can (mostly) already implement try() in userland
Unless I misunderstand the proposal - which I probably do — here is try() in the Go Playground implemented in userland, albeit with just one (1) return value and returning an interface instead of the expected type:
package main

import (
	"errors"
	"fmt"
	"strings"
)
func main() {
	defer func() {
		r := recover()
		if r != nil && strings.HasPrefix(r.(string),"TRY:") {
			fmt.Printf("Ouch! %s",strings.TrimPrefix(r.(string),"TRY: "))
		}
	}()
	n := try(badjuju()).(int)
	fmt.Printf("Just chillin %dx!",n)
}
func badjuju() (int,error) {
	return 10, errors.New("this is a really bad error")
}
func try(args ...interface{}) interface{} {
	err,ok := args[1].(error)
	if ok && err != nil {
		panic(fmt.Sprintf("TRY: %s",err.Error()))
	}
	return args[0]
}

So the user could add a try2(), try3() and so on depending on how many return values they needed to return.
But Go would only need one (1) simple yet universal language feature to allow users who want try() to roll their own support, albeit one that still requires explicit type assertion. Add a (fully backward-compatible) capability for a Go func to return a variadic number of return values, e.g.:
func try(args ...interface{}) ...interface{} {
	err,ok := args[1].(error)
	if ok && err != nil {
		panic(fmt.Sprintf("TRY: %s",err.Error()))
	}
	return args[0:len(args)-2]
}

And if you address generics first then the type assertions would not even be necessary (although I think the use-cases for generics should be whittled down by adding builtins to address generic's use-cases rather than add the confusing semantics and syntax salad of generics from Java et. al.)
Lack of obviousness
When studying the proposal's code I find that the behaviour is non-obvious and somewhat hard to reason about.
When I see try() wrapping an expression, what will happen if an error is returned?
Will the error just be ignored?  Or will it jump to the first or the most recent defer, and if so will it automatically set a variable named err inside the closure that, or will it pass it as a parameter (I don't see a parameter?). And if not an automatic error name, how do I name it?  And does that mean I can't declare my own err variable in my function, to avoid clashes?
And will it call all defers? In reverse order or regular order?
Or will it return from both the closure and the func where the error was returned? (Something I would never have considered if I had not read here words that imply that.)
After reading the proposal and all the comments thus far I still honestly do not know the answers to the above questions. Is that the kind of feature we want to add to a language whose advocates champion as being "Captain Obvious?"
Lack of control
Using defer, it appears the only control developers would be afforded is to branch to (the most recent?) defer. But in my experience with any methods beyond a trivial func it is usually more complicated than that.
Often I have found it to be helpful to share aspect of error handling within a func — or even across a package — but then also have more specific handling shared across one or more other packages.
For example, I may call five (5) func calls that return an error() from within another func; let's label them A(), B(), C(), D(), and E(). I may need C() to have its own error handling, A(), B(), D(), and E() to share some error handling, and B() and E() to have specific handling.
But I do not believe it would be possible to do that with this proposal. At least not easily.
Ironically, however, Go already has language features that allow a high level of flexibility that does not need to be limited to a small set of use-cases; funcs and closures. So my rhetorical question is:

"Why can't we just add slight enhancements to the existing language to address these use-cases and not need to add new builtin functions or accept confusing semantics?"

It is a rhetorical question because I plan to submit a proposal as an alternative, one that I conceived of during the study of this proposal and while considering all its drawbacks.
But I digress, that will come later and this comment is about why the current proposal needs to be reconsidered.
Lack of stated support for break
This may feel like it comes out of left field as most people use early returns for error handling, but I have found it is be preferable to use break for error handling wrapping most or all of a func prior to return.
I have used this approach for a while and its benefits in easing refactoring alone make it preferable to early return, but it has several other benefits including single exit point and ability to terminate a section of a func early but still be able to run cleanup (which is probably why I so rarely use defer, which I find harder to reason about in terms of program flow.)
To use break instead of early return use a for range "1" {...} loop to create a  block for the break to exit from (I actually create a package called only that only contains a constant called Once with a value of "1"):
func (me *Config) WriteFile() (err error) {
	for range only.Once {
		var j []byte
		j, err = json.MarshalIndent(me, "", "    ")
		if err != nil {
			err = fmt.Errorf("unable to marshal config; %s",
				err.Error(),
			)
			break
		}
		err = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
		if err != nil {
			err = fmt.Errorf("unable to make directory'%s'; %s",
				me.GetDir(),
				err.Error(),
			)
			break
		}
		err = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
		if err != nil {
			err = fmt.Errorf("unable to write to config file '%s'; %s",
				me.GetFilepath(),
				err.Error(),
			)
			break
		}
	}
	return err
}

I plan to blog about the pattern at length in the near future, and discuss the several reasons why I have found it to work better than early returns.
But I digress. My reason from bringing it up here is I would have for Go to implement error handling that assumes early returns and ignores using break for error handling
My opinion err == nil is problematic
As further digression, I want to bring up the concern I have felt about idiomatic error handling in Go.  While I am a huge believer of Go's philosophy to handle errors when they occur vs. using exception handling I feel the use of nil to indicate no error is problematic because I often find I would like to return a success message from a routine — for use in API responses — and not only return a non-nil value just when there is an error.
So for Go 2 I would really like to see Go consider adding a new builtin type of status and three builtin  functions iserror(), iswarning(), issuccess(). status could implement error — allowing for much backward compatibility and a nil value passed to issuccess() would return true — but status would have an additional internal state for error level so that testing for error level would always be done with one of the builtin functions and ideally never with a nil check.  That would allow something like the following approach instead:
func (me *Config) WriteFile() (sts status) {
	for range only.Once {
		var j []byte
		j, sts = json.MarshalIndent(me, "", "    ")
		if iserror(sts) {
			sts.AddMessage("unable to marshal config")
			break
		}
		sts = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
		if iserror(sts) {
			sts.AddMessage("unable to make directory'%s'", me.GetDir())
			break
		}
		sts = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
		if iserror(sts) {
			sts.AddMessage("unable to write to config file '%s'",
				me.GetFilepath(),
			)
			break
		}
		sts = fmt.Status("config file written")
	}
	return sts
}

I am already using a userland approach in a pre-beta level currently internal-use package that is similar to the above for error handling. Frankly I spend a lot less time thinking about how to structure code when using this approach than when I was trying to follow idiomatic Go error handling.
If you think there is any chance of evolving idiomatic Go code to this approach, please take it into consideration when implementing error handling, including when considering this try() proposal.
"Not for everyone" justification
One of the key responses from the Go team has been "Again, this proposal does not attempt to solve all error handling situations."
And that is probably the most troubling concern, from a governance perspective.
Does this new complicating change to the language that will require everyone to learn the new concepts really address a compelling number of use-cases?
And is that not the same justification members of the core team have denied numerous feature requests from the community? The following is a direct quote from comment made by a member of the Go team in an archetypical response to a feature request submitted about 2 years ago (I'm not naming the person or the specific feature request because this discussion should not be able the people but instead about the language):

"A new language feature needs compelling use cases. All language features are useful, or nobody would propose them; the question is: are they useful enough to justify complicating the language and requiring everyone to learn the new concepts? What are the compelling use cases here? How will people use these? For example, would people expect to be able to ... and if so how would they do that? Does this proposal do more than let you...?"
— A core Go team member

Frankly when I have seen those responses I have felt one of two feelings:

Indignation if it is a feature I do agree with, or
Elation if it is a feature I do not agree with.

But in either case my feelings were/are irrelevant; I understand and agree that part of the reason Go is the language so many of us choose to develop in is because of that jealous guarding of the purity of the language.

(And I truly hope the team will not shoot the messenger and take this as constructive criticism from someone who wants to see Go continue being the best it can be for all of us as I would have to be considered "Persona non grata" by the core team.)
If requiring a compelling set of real-world use-cases is the bar for all community-generated feature proposals, should it not also be the same bar for all feature proposals?
Nesting of try()
This too was covered by a few, but I want to draw comparison between try() and the continued request for ternary operators. Quoting from another Go team member's comments about 18 months ago:

"when "programming in the large" (large code bases with large teams over long periods of time), code is read WAY more often than it's written, so we optimize for readability, not writability."

One of the primary stated reasons for not adding ternary operators is that they are hard to read and/or easy to misread when nested. Yet the same can be true of nested try() statements like try(try(try(to()).parse().this)).easily()).
Additional reasons for argue against ternary operators have been that they are "expressions" with that argument that nested expressions can add complexity.  But does not try() create a nestable expression too?
Now someone here said "I think examples like [nested try()s] are unrealistic" and that statement was not challenged.
But if people accept as postulate that developers won't nest try() then why is the same deference not given to ternary operators when people say "I think deeply nested ternary operators are unrealistic?"
Bottom line for this point, I think if the argument against ternary operators are really valid, then they also should be considered valid arguments against this try() proposal.
In summary
At the time of this writing the 58% down votes to 42% up votes. I think this alone should be enough to indicate that this is divisive enough of a proposal that it is time to return to the drawing board on this issue.
#fwiw

@beoran Perhaps you could expand on the connection between generics and error handling.

Not speaking for @beoran but in my comment from a few minutes ago you'll see that if we had generics (plus variadic return parameters) then we could build our own try().
However — and I will repeat what I said above about generics here where it will be easier to see:

" I think the use-cases for generics should be whittled down by adding builtins to address generic's use-cases rather than add the confusing semantics and syntax salad of generics from Java et. al.)"

@ianlancetaylor
When trying to formulate an answer to your question, I tried to implement the try function in Go as it is, and to my delight, it's actually already possible to emulate something quite similar:
func try(v interface{}, err error) interface{} {
   if err != nil {
     panic(err)
   }
   return v
}

See here how it can be used:  https://play.golang.org/p/Kq9Q0hZHlXL
The downsides to this approach are:

A deferred rescue is needed, but with try as in this proposal, a deferred handler is also needed if we want to do proper error handling. So I feel this is not a serious downside. It could even be better if Go had some kind of super(arg1, ..., argn)  builtin causes the caller of the caller, one level up the call stack, to return with  the given arguments arg1,...argn, a sort of super return if you will.
This tryI implemented can only work with a function that returns a single result and an error.
You have to type assert the returned emtpy interface results.

Sufficiently powerful generics could resolve problem 2 and 3, leaving only 1, which could be resolved by adding a super() .  With those two features in place, we could get something like:
func (T ... interface{})try(T, err error) super {
   if err != nil {
      super(err)
   }
  super(T...)
}

And then the deferred rescue would not be needed anymore. This benefit would be available even if no generics are added to Go.
Actually, this idea of a super() builtin is so powerful and interesting I might post a proposal for it separately.

@beoran Good to see we came to exactly the same constraints independently regarding implementing try() in userland. :-)

I like the proposal but the fact you had to explicitly specify that defer try(...) and go try(...) are disallowed made me think something was not quite right.... Orthogonality is a good design guide. On further reading and seeing things like
x = try(foo(...))
y = try(bar(....))

I wonder if may be try needs to be a context! Consider:
try (
    x = foo(...)
    y = bar(...)
)

Here foo() and bar() return two values, the second of which is error. Keyword try only matters when the returned error value is ignored by eliding it as opposed ignoring it with _. You can even handle some errors in between foo and bar calls.
Summary:
a) the problem of disallowing try for go and defer disappears by virtue of the syntax.
b) error handling of multiple functions can be factored out.
c) its magic nature is better expressed as special syntax than as a function defn.

If try is a context then we've just made try/catch blocks which we're specifically trying to avoid (and for good reason)

There is no catch. Exact same code would be generated as when the current proposal has
x = try(foo(...))
y = try(bar(...))

This is just different syntax, not semantics.

I guess I had made a few assumptions about it that I shouldn't have done, although there's still a couple drawbacks to it.
What if foo or bar do not return an error, can they be placed in the try context as well? If not, that seems like it'd be kinda ugly to switch between error and non-error functions, and if they can, then we fall back to the issues of try blocks in older languages.
The second thing is that ypically the keyword ( ... ) syntax means you prefix the keyword on each line. So for import, var, const, etc: each line starts with the keyword. Making an exception to that rule doesn't seem like a good decision

Instead of using a function, would just be more idiomatic using a special identifier?
We already have the blank identifier _ which ignores values.
We could have something like # which can only be used in functions which have the last returned value of type error.
func foo() (error) {
	f, # := os.Open()
	defer f.Close()
	_, # = f.WriteString("foo")
	return nil
}

when a error is assigned to # the function returns immediately with the error received. As for the other variables their values would be:

if they are not named zero value
the value assigned to the named variables otherwise

@deanveloper, the try block semantics only matter for functions that return an error value and where the error value is not assigned. So the last example of present proposal could also be written as
try(x = foo(...))
try(y = bar(...))

putting both statements within the same block is simiar to what we do for  repeatedimport, const and var statements.
Now if you have, e.g.
try(
    x = foo(...))
    go zee(...)
    defer fum()
    y = bar(...)
)

This is equivalent to writing
try(x = foo(...))
go zee(...)
defer fum()
try(y = bar(...))

Factoring out all of that in one try block makes it less busy.
Consider
try(x = foo())

If foo() doesn't return an error value, this is equivalent to
x = foo()

Consider
try(f, _ := os.open(filename))

Since returned error value is ignored, this is equivalent to just
f, _ := os.open(filename)

Consider
try(f, err := os.open("/etc/passwd"))

Since returned error value is not ignored, this is equivalent to just
f, err := os.open("/etc/passwd")
if err != nil {
    return ..., err
}

As currently specified in the proposal.

Here is a link to the alternate proposal I mentioned above:

https://github.com/golang/go/issues/32473

It calls for adding two (2) small but general purpose language features to address the same use cases as try()

Ability to call a func/closure in an assignment statement.
Ability to break, continue or return more than one level.

With this two features their would be no "magic" and I believe their usage would produce Go code that is easier to understand and more inline with the idiomatic Go code we are all familiar with.

I've read the proposal and really like where try is going.
Given how prevalent try is going to be, I wonder if making it a more default behavior would make it easier to handle.
Consider maps.  This is valid:
v := m[key]
as is this:
v, ok := m[key]
What if we handle errors exactly the way try suggests, but remove the builtin.  So if we started with:
v, err := fn()
Instead of writing:
v := try(fn())
We could instead write:
v := fn()
When the err value is not captured, it gets handled exactly as the try does.  Would take a little getting used to, but it feels very similar to v, ok := m[key] and v, ok := x.(string).  Basically, any unhandled error causes the function to return and the err value to be set.
To go back to the design docs conclusions and implementation requirements:
• The language syntax is retained and no new keywords are introduced
• It continues to be syntactic sugar like try and hopefully is easy to explain.
• Does not require new syntax
• It should be completely backward compatible.
I imagine this would have nearly the same implementation requirements as try as the primary difference is rather than the builtin triggering the syntactic sugar, now it's the absence of the err field.

i would prefer syntax like that:

@savaki I like this and was thinking about what it would take to make Go flip the error handling by always handling errors by default and let the programmer specify when not to do so (by capturing the err into a variable) but total lack of any identifier would make code hard to follow as one wouldn't be able to see all the return points. May be a convention to name functions that could return an error differently could work (like capitalizing public identifiers). May be if a function returned an error, it must always end with, let's say ?. Then Go could always implicitly handle the error and automatically return it to the calling function just like try. This makes it very similar to some proposals suggesting to use a ? identifier instead of try but an important difference is that here ? would be part of the name of the function and not an additional identifier. In fact a function that returned error as the last return value wouldn't even compile if not suffixed ?. Of course ? is arbitrary and could be replaced with anything else that made the intent more explicit. operation?() would be equivalent to wrapping try(someFunc()) but ? would be part of the function name and it's sole purpose would be to indicate that the function can return an error just like the capitalizing the first letter of a variable.
This superficially ends up being very similar to other proposals asking to replace try with ? but a critical difference is that makes error handling implicit (automatic) and instead makes ignoring (or wrapping) errors explicit which kind of a best practice anyway. The most obvious problem with this of course is that it is not backward compatible and I'm sure there are many more.
That said, I'd be very interested in seeing how Go can make error handling the default/implicit case by automating it and let the programmer write a bit of extra code to ignore/override the handling. The challenge I think is how to make all the return points obvious in this case. One could say this is the same as implementing try and making errcheck a compiler failure.

why can't we just apply try | catch mechanics like in c++, with decorators for old functions.

could we do something like c++ exceptions with decorators for old functions?
func some_old_test() (int, error){ 	return 0, errors.New("err1") } func some_new_test() (int, error){ 	throw errors.New("err2") } func throw_res(int, e error) int { 	if e != nil { 		throw e 	} 	return int } func main() { 	fmt.Println("Hello, playground") 	try{ 		i := throw_res(some_old_test()) 		fmt.Println("i=", i) 	} catch(err io.Error) { 		return err 	} catch(err error) { 		fmt.Println("unknown err", err) 	} }

@owais I was thinking the semantics would be exactly the same as try so at the very least you would need to declare the err type.  So if we started with:
func foo() error {
  _, err := fn()
  if err != nil {
    return err
  }

  return nil
}

If I understand the try proposal, simply doing this:
func foo() error {
  _  := fn()
  return nil
}

would not compile.  One nice perk is that it gives the compile an opportunity to tell the user what's missing.  Something to the effect that using implicit error handling requires the error return type to be named, err.
This then, would work:
func foo() (err error) {
  _  := fn()
  return nil
}

why not just use handle the case of an error that isn't assigned to a variable.

remove need for named returns, compiler can do this all on its own.
allows for adding context
deals with the 90% of if statements just fine.

implicit return for the if err != nil case, compiler can generate local variable name for error return if necessary can't be accessed by the programmer.
f := os.Open("foo.txt")

adding context, also local naming of the variable. return becomes explicit because we want to add context.
f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

adding context with multiple return values
f := os.Open("foo.txt"); err {
  return i, j, errors.Wrap(err, "some context")
}

nested functions require that the outer functions handle all results in the same order
minus the final error.
bits := ioutil.ReadAll(os.Open("foo")); err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

compiler refuses compilation due to missing error return value in function
func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

happily compiles because error is explicitly ignored.
func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
}

@savaki I think I understood your original comment and I like the idea of Go handling errors by default but I don't think it's viable without adding some additional syntax changes and once we do that, it becomes strikingly similar to the current proposal.
The biggest downside to what you propose is that it doesn't expose all the points from where a function can return unlike current if err != nil {return err} or the try function introduced in this proposal. Even though it would function exactly the same way under the hood, visually the code would look very different. When reading code, there would be no way of knowing which function calls might return an error. That would end up being a worse experience than exceptions IMO.
May be error handling could be made implicit if the compiler forced some semantic convention on functions that could return errors. Like they must start or end with a certain phrase or character. That'd make all return points very obvious and I think it'd be better than manual error handling but not sure how significantly better considering there are already lint checks that cry out load when they spot an error being ignored. It'd be very interesting to see if the compiler can force functions to be named a certain way depending on whether they could return possible errors.

The main drawback of this approach is that the error result parameter needs to be named, possibly leading to less pretty APIs (but see the FAQs on this subject). We believe that we will get used to it once this style has established itself.

Not sure if something like this have been suggested before, can't find it here or in the proposal. Have you considered another builtin function that returns a pointer to the current function's error return value?
eg:
func example() error {
        var err *error = funcerror() // always return a non-nil pointer
        fmt.Print(*err) // always nil if the return parameters are not named and not in a defer

        defer func() {
                err := funcerror()
                fmt.Print(*err) // "x"
        }

        return errors.New("x")
}

func exampleNamed() (err error) {
        funcErr := funcerror()
        fmt.Print(*funcErr) // "nil"

        err = errors.New("x")
        fmt.Print(*funcErr) // "x", named return parameter is reflected even before return is called

        *funcErr = errors.New("y")
        fmt.Print(err) // "y", unfortunate side effect?

        defer func() {
                funcErr := funcerror()
                fmt.Print(*funcErr) // "z"
                fmt.Print(err) // "z"
        }

        return errors.New("z")
}

usage with try:
func CopyFile(src, dst string) (error) {
        defer func() {
                err := funcerror()
                if *err != nil {
                        *err = fmt.Errorf("copy %s %s: %v", src, dst, err)
                }
        }()
        // one liner alternative
        // defer fmt.HandleErrorf(funcerror(), "copy %s %s", src, dst)

        r := try(os.Open(src))
        defer r.Close()

        w := try(os.Create(dst))
        defer func() {
                w.Close()
                err := funcerror()
                if *err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try(io.Copy(w, r))
        try(w.Close())
        return nil
}

Alternatively funcerror (the name is a work in progress :D ) could return nil if not called inside defer.
Another alternative is that funcerror returns an "Errorer" interface to make it read-only:
type interface Errorer() {
        Error() error
}

@savaki I actually do like your proposal to omit try() and allow it to be more like testing a map or a type assertion.
However, there is still one glaring issue I see, and that is your proposal presumes that all errors using this approach will trigger a return and leave the function.  What it does not contemplate is issuing a break out of the current for or a continue for the current for.
Early returns are a sledgehammer when many times a scalpel is the better choice.
So I assert break and continue should be allowed to be valid error handling strategies and currently both your proposal presumes only return whereas try() presumes that or calling an error handler that itself can only return, not break or continue.

Looks like savaki and i had similar ideas, i just added the block semantics for dealing with the error if desired. For example adding comtext, for loops where you want to short circuit etc

@mikesckinkel see my extension, he and i had similar ideas i just extended it with an optional block statement

@mikesckinkel see my extension, he and i had similar ideas i just extended it with an optional block statement

Taking your example:
f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

Which compares to what we do today:
f,err := os.Open("foo.txt");
if err != nil {
  return errors.Wrap(err, "some context")
}

Is definitely preferable to me. Except it has a few issues:

err appears to be "magically" declared.  Magic should be minimized, no? So let's declare it:

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

But that still does not work because Go does not interpret nil values as false nor pointer values as true, so it would need to be:

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

And what that works, it starts to feel like just as much work and a lot of syntax on one line, so and I might continue to do the old way for clarity.
But that is Go added to builtins; iserror() and error()? Then we could do this, which does not feel as bad to me:
f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

What do you, and other think?
As an aside, check my username spelling. I would not have been notified of your mention if I wasn't paying attention anyway...

@mikeschinkel sorry about the name I was on my phone and github wasn't autosuggesting.

err appears to be "magically" declared. Magic should be minimized, no? So let's declare it:

meh, the entire idea of automatically inserting a return is magical. this is hardly the most magical thing going on in this entire proposal. Plus I'd argue the err was declared; just at the end inside a scoped block's context preventing it from polluting the parent scope while still maintaining all the good stuff we get normally with using if statements.
I'm generally pretty happy withs go's error handling with the upcoming additions to the errors package. I don't see anything in this proposal as super helpful. I'm just attempting to offer the most natural fit for the golang if we're dead set on doing it.

"the entire idea of automatically inserting a return is magical."

You won't get any argument from me there.

"this is hardly the most magical thing going on in this entire proposal."

I guess I was trying to argue that "all magic is problematic."

"Plus I'd argue the err was declared; just at the end inside a scoped block's context..."

So if I wanted to call it err2  this would work too?
f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

So I assume you are also proposing special case handling of the err/err2 after the semi-colon, i.e. that it would be assumed to be either nil or not nil instead of bool like when checking a map?
if _,ok := m[a]; ok {
   print("there is no 'a' in 'm'")
}

I'm generally pretty happy withs go's error handling with the upcoming additions to the errors package.

I too am happy with error handling, when combined with break and continue (but not return).
As it is, I see this try() proposal as more harmful than helpful, and would rather see nothing than this implement as-proposed.  #jmtcw.

@beoran @mikeschinkel Earlier I suggested that we could not implement this version of try using generics, because it changes the control flow.  If I'm reading correctly, you are both suggesting that we could use generics to implement try by having it call panic.  But this version of try very explicitly does not panic.  So we can't use generics to implement this version of try.
Yes, we could use generics (a version of generics significantly more powerful than the one in the design draft at https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md) to write a function that panics on error.  But panicking on error is not the kind of error handling that Go programmers write today, and it doesn't seem like a good idea to me.

@mikeschinkel special handling would be that the block executes only when there is an error.
f := os.Open('foo'); err { return err } // err would always be non-nil here.

@ianlancetaylor

"Yes, we could use generics ... But panicking on error is not the kind of error handling that Go programmers write today, and it doesn't seem like a good idea to me."

I actually strongly agree with you on this thus it appears you may have misinterpreted the intent of my comment.  I was not at all suggesting that the Go team would implement error handling that used panic() — of course not.
Instead I was trying to actually follow your lead from many of your past comments on other issues and suggested that we avoid making any changes to Go that are not absolutely necessary because they are instead possible in userland.  So if generics were addressed then people who would want try() could in fact implement it themselves, albeit by leveraging panic().  And that would be one less feature that the team would need to add to and document for Go.
What I was not doing — and maybe that was not clear — was advocating that people actually use panic() to implement try(), just that they could if they really wanted to, and they had the features of generics.
Does that clarify?

To me calling panic, however that is done, is quite different from this proposal for try.  So while I think I understand what you are saying, I do not agree that they are equivalent.  Even if we had generics powerful enough to implement a version of try that panics, I think there would still be a reasonable desire for the version of try presented in this proposal.

@ianlancetaylor Acknowledged.  Again, I was looking for a reason that try() would not need to be added rather than find a way to add it. As I said above, I would far rather not have anything else for error handling than have try() as proposed here.

I personally liked the earlier check proposal more than this, based on purely visual aspects; check had the same power as this try() but bar(check foo()) is more readable to me than bar(try(foo())) (I just needed a second to count the parens!).
More importantly, my main gripe about handle/check was that it didn't allow wrapping individual checks in different ways -- and now this try() proposal has the same flaw, while invoking tricky rarely-used newbie-confusing features of defers and named returns. And with handle at least we had the option of using scopes define handle blocks, with defer even that isn't possible.
As far as I'm concerned, this proposal loses to the earlier handle/check proposal in every single regard.

Here's another concern with using defers for error handling.
try is a controlled/intended exit from a function. defers run always, including uncontrolled/unintended exits from functions. That mismatch could cause confusion. Here's an imaginary scenario:
func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

Recall that net/http recovers from panics, and imagine debugging a production issue around the panic. You'd look at your instrumentation and see a spike in db call failures, from the recordMetric calls. This might mask the true issue, which is the panic in the subsequent line.
I'm not sure how serious a concern this is in practice, but it is (sadly) perhaps another reason to think that defer is not an ideal mechanism for error handling.

Here's a modification that may help with some of the concerns raised: Treat try like a goto instead of like a return. Hear me out. :)
try would instead be syntactic sugar for:
t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te   // assign te to the error result parameter
        goto error // goto "error" label
}
x1, … xn = t1, … tn  // assignment only if there was no error

Benefits:

defer is not required to decorate errors. (Named returns are still required, though.)
Existence of error: label is a visual clue that there is a try somewhere in the function.

This also provides a mechanism for adding handlers that sidesteps the handler-as-function problems: Use labels as handlers. try(fn(), wrap) would goto wrap instead of goto error. The compiler can confirm that wrap: is present in the function. Note that having handlers also helps with debugging: You can add/alter the handler to provide a debugging path.
Sample code:
func CopyFile(src, dst string) (err error) {
    r := try(os.Open(src))
    defer r.Close()

    w := try(os.Create(dst))
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    try(io.Copy(w, r), copyfail)
    try(w.Close())
    return nil

error:
    return fmt.Errorf("copy %s %s: %v", src, dst, err)

copyfail:
    recordMetric("copy failure") // count incidents of this failure
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

Other comments:

We might want to require that any label used as the target of a try be preceded by a terminating statement. In practice, this would force them to the end of the function and could prevent some spaghetti code. On the other hand, it might prevent some reasonable, helpful uses.
try could be used to create a loop. I think this falls under the banner of "if it hurts, don't do it", but I'm not sure.
This would require fixing https://github.com/golang/go/issues/26058.

Credit: I believe a variant of this idea was first suggested by @griesemer in person at GopherCon last year.

@josharian Thinking about the interaction with panic is important here, and I'm glad you brought it up, but your example seems strange to me. In the following code it doesn't make sense to me that the defer always records a "db call failed" metric. It would be a false metric if someHTTPHandlerGuts succeeds and returns nil. The defer runs in all exit cases, not just error or panic cases, so the code seems wrong even if there is no panic.
func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

@josharian Yes, this is more or less exactly the version we discussed last year (except that we used check instead of try). I think it would be crucial that one couldn't jump "back" into the rest of the function body, once we are at the error label. That would ensure that the goto is somewhat "structured" (no spaghetti code possible). One concern that was brought up was that the error handler (the error:) label would always end up at the end of the function (otherwise one would have to jump around it somehow). Personally, I like the error handling code out of the way (at the end), but others felt that it should be visible right at the start.

@mikeshenkel I see returning from a loop as a plus rather than a negative.  My guess is that would encourage developers to either use a separate function to handle the contents of a loop or explicitly use err as we currently do.  Both of these seem like good outcomes to me.
From my POV, I don’t feel like this try syntax has to handle every use case just like I don’t feel that I need to use the
V, ok:= m[key]
Form from reading from a map


⚠ Turnos 24x7 has degraded performance

In a14e7a5, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 839 ms

Resolved: Turnos 24x7 performance has improved in 55a159b.


Modern annotations in css

Part 1 to fix https://github.com/Infleqtion/server-superstaq/issues/2969

@pgoiporia Please review.

@bharat-thotakura let's merge this and #858 before they accumulating merge conflicts
(i also filed https://github.com/Infleqtion/qLDPC/pull/1 so its tests will continue to pass after #858 despite its old-style annotations)


Delete doesn't work for outdated templates

I changed a few templates and now delete (through the GUI, on the workflow page doesn't work). My only option is to delete the entire experiment.

Upon closer inspection, it does work. It gives an error when you try, but when you refresh, the processes are gone.


BOM items are not listed

Please verify that this bug has NOT been raised before.

[X] I checked and didn't find a similar issue

Describe the bug*
The BOM list items for the parts is empty since yesterday. See the screenshot please.

As you can see there are actually 30 rows of BOM items assigned to this part. However none of them are listed somehow.
The bad part is that I don't know how this happened hence can't provide any steps to reproduce unless you give me some tips to do it.
I've tried refreshing the page both with F5 and  CTRL + F5 with no avail. Then I went to the admin panel to check whether the BOM items are still exist, I see them in there.
I also tried to add a new BOM item to see if it will be shown in the list, but it did not either.
Why something like this would happen? What should I do?
Steps to Reproduce
Not sure how this happened...
Expected behaviour
The BOM items of the part to be listed.
Deployment Method

[X] Docker
[ ] Package
[ ] Bare metal
[ ] Other - added info in Steps to Reproduce

Version Information
Version Information:
InvenTree-Version: 0.16.1
Django Version: 4.2.15
Commit Hash: 4c15e5c
Commit Date: 2024-08-30
Database: postgresql
Debug-Mode: False
Deployed using Docker: True
Platform: Linux-6.8.0-40-generic-x86_64-with
Installer: DOC
Active plugins: [{'name': 'InvenTreeBarcode', 'slug': 'inventreebarcode', 'version': '2.1.0'}, {'name': 'InvenTreeCoreNotificationsPlugin', 'slug': 'inventreecorenotificationsplugin', 'version': '1.0.0'}, {'name': 'InvenTreeCurrencyExchange', 'slug': 'inventreecurrencyexchange', 'version': '1.0.0'}, {'name': 'InvenTreeLabel', 'slug': 'inventreelabel', 'version': '1.1.0'}, {'name': 'InvenTreeLabelMachine', 'slug': 'inventreelabelmachine', 'version': '1.0.0'}, {'name': 'InvenTreeLabelSheet', 'slug': 'inventreelabelsheet', 'version': '1.0.0'}, {'name': 'DigiKeyPlugin', 'slug': 'digikeyplugin', 'version': '1.0.0'}, {'name': 'LCSCPlugin', 'slug': 'lcscplugin', 'version': '1.0.0'}, {'name': 'MouserPlugin', 'slug': 'mouserplugin', 'version': '1.0.0'}, {'name': 'TMEPlugin', 'slug': 'tmeplugin', 'version': '1.0.0'}, {'name': 'IPNGenerator', 'slug': 'ipngen', 'version': '0.1'}, {'name': 'KiCadLibraryPlugin', 'slug': 'kicad-library-plugin', 'version': '1.4.3'}]
Please verify if you can reproduce this bug on the demo site.

[ ] I can reproduce this bug on the demo site.

Relevant log output
No response

@JustusRijke have you tried refreshing the cache on your browser?
https://docs.inventree.org/en/latest/faq/#feature-x-does-not-work-after-update

@kozmotronik can you please open the developer console in your browser and share (screenshots please) what the "requests" or "network" tab shows when you try to reload that table? i.e. by pressing the "reload data" button:

Sure, here it is:

By the way, I logged in to InvenTree from Vivaldi browser, the BOM list appeared in it. The browser that I am having problem with is the KDE's Falkon browser. I use it because it is lightweight and fast. But if it is not compatible I can ditch it from using for InvenTree.
What do you advice me?

Oh my! It turns out that it is a browser specific caching issue. CTRL +F5 does not seem to work in Falkon browser. So I cleared the cache from the settings and restarted the browser then boom! The BOM items returned.
I'd like to apologize for consuming of your valuable time for this insignificant browser specific issue. Excuse me please and thank you.

@kozmotronik thanks for getting back with the outcome. Glad to hear that you got it sorted!


NPM Module not installing dependencies

Hello,
I've installed famous-map like this:
npm install famous-map --save-dev

And when I run it, using this:
var MapView = require('famous-map/MapView');

I get this error in the console:
Error: Cannot find module 'deamdify' from '/Users/antoniobrandao/WEBROOT/vv_app/node_modules/famous-map'

Looking at the node_modules folder, I saw that the dependencies are not being installed:
http://cl.ly/image/3n1Q082w0n25

It seems to me, by looking at other NPM modules in my project, that NPM modules by default install the dependencies listed in "dependencies", but not those in "devDependencies".
If this is right, moving "deamdify" to "dependencies" instead of "devDependencies" will solve this. Famous-map didn't complain about the other modules after I installed "deamdify" separately.

I've made a pull request with this change to save you the hassle if you approve of it.

Hi, thanks for pointing this out!
I just did a little bit of research and I'm pretty sure I can remove all of those dependencies entirely. I'll make the change, if you could test with the new package.json and verify that it works for you, that would be awesome. I'll make the commit and share the link here.

Updated package.json:
https://github.com/IjzerenHein/famous-map/commit/93d63a777047d6e91673b8dc0f0dad47e599dcbd

Can you please update/re-publish the NPM module? It doesn't have the new package.json yet

But before doing that you might want to look at this one https://github.com/IjzerenHein/famous-map/issues/13 :)

Hi, I've just released a new version without the unnecessary browserify dependencies. Let me know how this works out for you. Cheers

Thanks so much for your dedication to this awesome module. I will answer to this thread later tonight after testing.

Awesome, let me know how it works out.