On Mon, 8 Jul 2019 07:37:20 -0500
Robert Engels <reng...@ix.netcom.com> wrote:
> This will never work because of dependent resource allocation.
> And you wouldn’t be able to check resources against nil if they are structs,
> so you have no way to properly cleanup up.
> If would quickly degenerate back to if err != nil.
If the functions called in the block follow bad practices -
yes, then the `check` will be harder[1] to use for them.
> As in
>
> check(err!=nil){
> token, err = getToken()
> reader,err = getReader(token)
> db,err = get DB(reader)
>
> catch:
> How do you know know which resources need to be closed/cleaned-up
Because I wrote the getToken and getReader and getDB to return zero
object on err and gave their .Clean() / .Close() methods ability to be invoked
multiple times ? :)
[1] // make bad implementations usable with check:
token := &tokenType{} // assume a pointer out of your "against nil"
reader := new(dummy.Reader)
db := new(mock.DB)
Anyway, your concerns are sound and need (documentation side) attention. Thank
you.
--
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/20190708145952.15da5f22%40zuzia.
For more options, visit https://groups.google.com/d/optout.
