Go proposal: Leave “if err != nil” alone?

Re:Go proposal: Leave “if err != nil” alone? by ernst_klim on Friday June 28, 2019 @05:03PM (#20308767)

IMHO the worst part of Go errors is that they are strings, so if you propagate them, you can't do anything but print them. You can't handle them properly, since you can't match them in a robust way.

Just compare how good the error handling is in OCaml: http://keleshev.com/composable-error-handling-in-ocaml

[ Parent | on HN ]

Re:Go proposal: Leave “if err != nil” alone? by alphabettsy on Friday June 28, 2019 @07:52PM (#20309816)

Huh? They’re not strings. They’re an interface and you can create your own error type that implements the error interface, one of the requirements being that it has a string output available.

[ Parent | on HN ]

Re:Go proposal: Leave “if err != nil” alone? by ernst_klim on Saturday June 29, 2019 @04:24AM (#20311448)

>They’re not strings.

They are strings. They are implementation of interface with a single `to_string` method, after you got `error`, you can't say (you could use switch on type, but you should guess which type could it be), so basically you have an opaque object with a single `to_string` method, which is equivalent to string.

I can't fancy a more error prone way than that which Go choose. How you match the errors, you match strings? You match types? You don't even know what types could there be, since all what the type system says is that function returns error.

[ Parent | on HN ]