On Thu, Nov 1, 2018 at 5:18 AM Laurent Moussault
<[email protected]> wrote:
>
> IMHO, this kind of refactorization actually makes the code less readable, for
> everyone but the programmer that just wrote it. Though it may seem obvious at
> first what functions like "CopyFile" do, an outsider reading the code will
> have to check the source to know for sure what is going on.
>
> When this kind of "factoring for simplification sake" is frequent enough, the
> simplest linear algorithm becomes a maze of sub-functions.
>
> I, for one, really like the check/handle proposal, because I think it is
> easier to read than the current code with interleaved ifs, while being as
> explicit:
>
> handle err {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> r := check os.Open(src)
> defer r.Close()
> w := check os.Create(dst)
> handle err {
> os.Remove(dst)
> }
> check io.Copy(w, r)
> check w.Close()
>
In my opinion, code like the one above is not readable at all. It is
not clear from the following code what will happen:
check io.Copy()
Code like this requires you read the whole function before looking at
this spot.
I like explicit errors with fewer lines of code, though. Something like this:
handle err { if err == someError { return fmt.Errorf(...} } }
err=check io.Copy()
err=check w.Close()
if err!=nil {
...
}
Above, err is an error variable with an associated handler. If err is
assigned a non-nil value, the handler is invoked. If the handler does
not handle the error, the err variable is still available to use.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
