Dnia 2021-02-21, o godz. 11:23:24
robert engels <reng...@ix.netcom.com> napisał(a):
> Can someone please explain the benefit of ‘error return’ over ‘checked
> exceptions’ ?
May you please explain the benefit of ‘checked exceptions’ over ‘return error
value’?
I stated and restated benefits of 'Go-way' earlier in this thread twice. I can
only add what IMO is wrong with java exceptions:
- failure context in scope is lost. Welcome back to the early C times and
declare everything you might need before you open the try block.
- you have to handle failures at distance. (Or sprinkle your code with
'try-catch-es in density similar to Go's if-err-not-nil-es.)
- you need to be aware of exceptional flows within flow of exceptions -
accounting for niceties that may vary from implementation to implementation of
prosthetic added to alleviate practical shortcomings of the whole exceptions
concept:
>>> If an exception is thrown from the try block and one or more exceptions are
>>> thrown from the try-with-resources statement, then those exceptions thrown
>>> from the try-with-resources statement are suppressed, and the exception
>>> thrown
>>> by the block is the one that is thrown by the writeToFileZipFileContents
>>> method.
>>> You can retrieve these suppressed exceptions by calling the
>>> Throwable.getSuppressed
>>> method from the exception thrown by the try block.
Exceptions in all their glory as seen in the wild (in Oracle Java docs).
> The ‘handle where they occur claim’ is weak, as you can handle exceptions at
> the call site with similar LOC and constructs - but why
> when in most cases (of non-trivial software) the error value is just returned
> up.
IMO "when in most cases…is just returned/thrown up" is an accessory damage done
to the generation exposed to exceptionally toxic fumes of convoluted exception
flows ;). No offense to Robert.
> No offense to Wojciech - the rpc transport layer doesn’t do the retires, it
> passes up an error, and a higher level performs retry logic, if all retries
> fail, it will pass up another error that the rpc failed, etc. This pattern is
> used throughout well designed software.
> If you hard using this pattern you are creating very hard to maintain
> software.
I hardly use other working with std libraries. But where I can I keep the unit
sealed, testable as a black-box and replaceable. Go helps with that.
> Checked exceptions are ‘error values’ with more information (e.g stack
> traces, causes, etc.)
This (more information everywhere) is also a fallacy stem mostly from the
exceptions philosophy. I need not to build objects and move piles of data my
code can not deal with. In Go I log this at the place of occurrence (for the
human consumption at debug/forensics time). All what code up needs to know is
whether this was a recoverable failure or an error. Try to recover if former,
give up and tell supervisor if later.
> Can be enforced by the compiler (declared) and inspected by modern IDE’s for
> code complete.
Um... What compiler can enforce inside an 'foff/todo' (empty) catch block? Note
that this empty catch can be silently placed way out of sight to not bother us
in our happy flow reading experience. In Go this attitude, while it takes just
two strokes, is visible in-place as a glaring lhs underscore.
> BUT you should not be using exceptions - or error values - for flow control.
WUT?
Every Java book 'exceptions' chapter starts along the 'use checked exceptions
for the flow control' lines:
>>> [Joshua Bloch, Effective java] Item 40: Use checked exceptions for
>>> recoverable conditions and runtime exceptions for programming errors. E.g.
>>> host is down, throw checked exception so the caller can either pass in a
>>> different host address or move on to something else.
>>> Item 41: Avoid unnecessary use of checked exceptions.
> This is the fundamental problem to me with Go’s error handling -
> the flow control and errors are mixed
Whether you want it or not, you must choose the path if a failure or an error
happens.
> leading to very difficult code to read
(In Go) leading to code that does what it says. And a code that says explicit
what it is about to do if just called piece of code did not know what to do.
All in sight. The happy path can be exposed in an IDE with a fold switch [see
PS].
>code difficult to validate that all potential paths are handled now and in the
>future.
Java compiler can validate only sad paths that it has been explicitly told of
using 'throws' clause. Hardly 'all potential…and in the future'.
All in all: both java and Go ways are already established and used. Both are
slowly evolving. Arguing them here over and over will not change Go usage
patterns with even an iota for the simple fact Go does not support exceptions.
P.S. You, Robert, could make a gift for others who'd like to have "lucid happy
path view" by amending mainstream IDEs folding code with "fold to finger"
functionality. I mean, let the IDE hide every `if err != nil` {; return err }`
block and display 👆 (U+1F446) next to the lhs err symbol instead:
/// Where such code
file, err := f.Open(name)
if err != nil {
return err
}
/// would display folded as
file, err👆 := f.Open(name)
///
That would be way more constructive than our yak-shaving here :)
TC,
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20210222153346.2d970dae%40xmint.
