3 ms·

In practice I'm not sure I see where a PotentiallyErorredResponse object that wraps a response and error together is different from returning a response and an

by dkuntz2 11y ago

In practice I'm not sure I see where a PotentiallyErorredResponse object that wraps a response and error together is different from returning a response and an error. The advantage of Optional over returning a value or null is partially that it makes the programmer more aware of the fact that they're dealing with something that might be null. The same thing would be true of an Errorable wrapper. I'd argue that Go makes it more explicit by having compile-time errors when you don't deal with potential error responses.

sanderjd 11y ago
The solutions are definitely similar, but the advantage is eliminating the potential for propagation of nil values. > I'd argue that Go makes it more explicit by having compile-time errors when you don't deal with potential error responses. Showing my ignorance: how does this work? Does the Go compiler check that you check the second return value from a method before doing something with the first return value? I thought you could just ignore the error return and pass along the returned value (which might be nil) as you please. If there's compiler support for avoiding nil propagation, that's great! In the case of a container type like I'm suggesting, you get the compile-time checking from the type system – an error return value is not of the same type as the underlying type, so you have to explicitly get the underlying value out. Even if you accidentally propagate the container, you probably have more information than if you propagate a naked nil, because the error information is part of the container that was propagated, rather than a separate value that might be lost.
- fauigerzigerk 11y ago
  >If there's compiler support for avoiding nil propagation, that's great! Yes, would be great, but there is no such compiler support. You can ignore errors completely. Maybe you could argue that compiler errors for unused variables are a very weak sort of compiler break on ignoring errors.
superskierpat 11y ago
One thing I liked about the Option type in java is that it not only offered better clarity, it also came with a few cool methods, like ifPresent()

by dkuntz2 11y ago

sanderjd 11y ago

The solutions are definitely similar, but the advantage is eliminating the potential for propagation of nil values. > I'd argue that Go makes it more explicit by having compile-time errors when you don't deal with potential error responses. Showing my ignorance: how does this work? Does the Go compiler check that you check the second return value from a method before doing something with the first return value? I thought you could just ignore the error return and pass along the returned value (which might be nil) as you please. If there's compiler support for avoiding nil propagation, that's great! In the case of a container type like I'm suggesting, you get the compile-time checking from the type system – an error return value is not of the same type as the underlying type, so you have to explicitly get the underlying value out. Even if you accidentally propagate the container, you probably have more information than if you propagate a naked nil, because the error information is part of the container that was propagated, rather than a separate value that might be lost.

fauigerzigerk 11y ago
>If there's compiler support for avoiding nil propagation, that's great! Yes, would be great, but there is no such compiler support. You can ignore errors completely. Maybe you could argue that compiler errors for unused variables are a very weak sort of compiler break on ignoring errors.

superskierpat 11y ago

One thing I liked about the Option type in java is that it not only offered better clarity, it also came with a few cool methods, like ifPresent()