[kenhwang]

It looks like instead of making a better error handling system, they just made it easier to not type `if err != nil` everywhere. Then there's all that handler stuff that looks very much like Java's `try ... catch` in reverse order.

Pretty underwhelming for what's supposed to be a modern language.

[jerf]

"Then there's all that handler stuff that looks very much like Java's `try ... catch` in reverse order."

The key characteristic of Go's error handling is that you have to handle errors in the scope in which they occur, vs. exception handing which is designed around throwing errors up the stack until something finally handles it, often quite distant from the point of the error and lacking context.

"try" just re-spells that. It isn't a step towards exception handling; it's exactly as "exception-handle-y" as if err != nil { return err } already is, whatever value you may consider that to be. Part of the goal is to make correct handling where you actually do something with the error that much easier, instead of having to do something essentially unrefactorable for every error, through a combination of allowing error handling to be factorable in this new scheme, and some other changes to errors to add more structure by convention to create official ways of composing them together and examining these composed errors in sensible ways.

[pacala]

The confusing part is the underlying assumption that there exists a way to "handle" errors, understood as a way to workaround the error and somehow continue execution. This is most of the times futile, there is nothing to "handle", other than abort the execution and report the condition.

For example, consider a bug that causes a data structure invariant to be violated. The correct "handling" of the situation is to fix the bug and rerun the code, not add layers and layers of error "handling" code ahead of time.

[jerf]

One of the things the Go community has encountered is chaining together too many "if err != nil { return err }" basically returns you to the exceptions problem of having no context around the error anymore, except now you don't even have a stack trace to help you out. (This is what I meant by the bare "if err != nil { return err }" being "exception-y", only, if you like, unambiguously worse if the code base is full of that literal block.)

"Handling" an error includes further annotating it with information about why the code in question couldn't fix it, and this is probably the most common case. (I hedge only because we humans are actually really bad at judging such things, with our availability heuristic bias and other biases. I'm fairly confident this would indeed be the #1 case, but I've been wrong about this sort of thing in the past when I actually went to check.) We don't mean "fix" the error, just... "handle". Ideally you end up with a composite error object (as I said, in conjunction with a few other library-level things that are likely to get pulled up to official support and culture) that contains much more information about the error, and that if you do end up flinging it up to higher level code, you're leaving it with more options for understanding the resulting problems and dealing with them.

[pacala]

The task of an error "handling" mechanism could be then described as:

A. Create an error object, enter "error mode".

B. Annotate an error object with contextual information at each call point.

C. Return the error object up the call stack.

D. Translate from "error mode" into "value mode", producing the annotated error object as a value.

For languages with exceptions, B is automatic, but limited to stack traces, C is automatic. A and D are obtained via special language constructs, for example "raise ... / try: ... except E as ex: ...".

For Go [please excuse my almost total ignorance], B is manual, but arbitrarily expressive, C is manual, but terse via "try(...)", whereas A and D are done using a combination of standard language constructs and style conventions.

Assuming the above is correct, perhaps there is some reasonable design that automates B for most common use-cases. In particular, logging the invocation arguments at D makes it trivial to re-run the offending code in a debugger, with full stack trace and invocation arguments. Wrapping most function calls with "try(...)" is annoying, but manageable, whereas thinking what information should be carried by the error object on a case by case basis is a waste of brain cycles.

[tptacek]

That's literally the case that "panic" is there to handle.

[pacala]

The example was a worst case example. There are weaker versions thereof, for example the familiar:

    def handle(request):
      try:
          return Response(200, process(request))
      except UserError as ex:
          return Response(400, ex.message)
      except InternalError as ex:
          return Response(500)

The principle stays the same, there is not much to "handle" and no option to recover without external help, either by providing a well-formed request for 400 errors or by providing well-behaving code for 500 errors.

[tptacek]

If an error is unrecoverable, panic. If all you're trying to do is generate a 500 error, net/http even handles the panic for you. If you're a library author and unsure of whether your callers want a panic or not, provide a normal and an (idiomatic) "Must" version that panics on the error.

There are legitimate criticisms to be made of how Go's error handling works, but I think the language already handles the case you're talking about.

[zellyn]

Is Go “supposed to be a modern language”? I'm not sure even the language designers would agree with that characterization.

[Thaxll]

What is a modern language anyway?

[pjmlp]

One that takes into account features that have made into the mainstream during the last 20 years, instead of feeling like an Algol-68 subset.

[paavohtl]

Hey, that's not fair for ALGOL 68. It had sum types, pattern matching and everything-is-an-expression [1].

[1] https://dl.acm.org/citation.cfm?id=356671

[unscaled]

I guess that's why Go is a subset :)

Although to be fair to Go, I don't think ALGOL 68 had a (slightly broken) implementation of CSP and HTTP/2.0 support in the standard library.

[geodel]

I see Javascript made it mainstream for all sort of clients and servers, Electron desktop apps made it to mainstream. So I remain skeptic to argument just because new features have been invented they are good or need to be implemented everywhere.

[pjmlp]

JavaScript enjoyed being the only option with regards to browser as platform.

Go is only inevitable for those that need to deal with Docker and Kubernetes, the NoSQL hype successors.

[tracker1]

Been a fan of JS since before The Good Parts book. Used it server-side in Classic ASP, Netscape Server and a couple more obscure runtimes before Node.js.

Personally, I find Rust as more approachable and easier to wrap my head around opposed to Go. Though some of the syntax changes I don't like as much. Waiting on async/await to land in a couple months though.

[Thaxll]

I don't care about the features in the last 20 years if I'm able to do my job efficiently which Go as a language provides. Never wonder why those great academics languages with a ton of features are not adopted?

[pjmlp]

So now languages like Java, Swift, Kotlin are academic languages?

[fwip]

Java is like 25 years old, you know.

[staticassertion]

If you don't care about literally decades of progress you're just a bad software developer.

[BlueTemplar]

Well, for one, it handles text as being UTF-8 by default, even at the lowest level (and in no case assumes that byte = character !)

[krferriter]

I would say it is a modern language or attempts to be one, as it was designed recently, and was able to take lessons from a variety of older languages. Rust and Go are probably the most popular general purpose, good performance modern languages. Swift and TypeScript are also pretty modern.

[staticassertion]

Go is new, not modern.

[pjmlp]

It still needs to catch up with CLU, released on 1973.

[AnimalMuppet]

In what way?

[pjmlp]

Generics to start with.

[tjholowaychuk]

Which can be solved with a snippet bound to `e`.

[eikenberry]

The problem `try` is addressing isn't typing the boilerplate, it is that it clutters up the code making it harder to read.

[dnautics]

it's not as if `if err != nil` doesn't clutter up the code!

[eikenberry]

Sorry, I said that poorly. I mean that the problem `try` is fixing is that all the `if err != nil ..` clutters up the code and they are introducing `try` to clean that up.