--- Log opened Wed Jun 03 00:00:40 2020
00:21 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #utreexo
03:04 -!- adiabat [~adiabat@63.209.32.102] has quit [Ping timeout: 246 seconds]
03:24 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
04:26 < rjected> ja: you're correct on the point of why the division operator panics on divide by zero for example, but function signatures in go pretty much always have (error) as a return argument. It's not polluting the type signature or anything, it's very normal to detect and propagate errors with a nil check in Go.
04:28 < rjected> https://eli.thegreenplace.net/2018/on-the-uses-and-misuses-of-panics-in-go/
04:32 < rjected> panics for sure *are* used in go, but if you look at the ratio of "if err != nil {return err}" to "if err != nil {panic(err)}" I think it would be something like 100:1
04:40 < rjected> also https://golang.org/doc/effective_go.html#panic
04:42 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #utreexo
04:59 -!- adiabat [~adiabat@63.209.32.102] has joined #utreexo
05:23 -!- dergoegge [dergoegge@gateway/vpn/nordvpn/dergoegge] has joined #utreexo
05:31 < dergoegge> ja: internal panics are ok i agree but i think exported functions should not panic, so maybe we should add a recovery from a panic for those (just in case).
05:34 < dergoegge> "The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values." - https://blog.golang.org/defer-panic-and-recover
05:38 < dergoegge> TIL that deferred functions still get executed when the function panics
06:30 < rjected> yep
06:41 < rjected> personal test for panics though: if it's in a cmd main, driver, fuzzer, test, or dealing with necessary updates to info on disk, it's probably ok to panic rather than return an error
07:11 < adiabat> I think panics are OK when it's something wrong with the programming that shouldn't be able to happen
07:11 < adiabat> I think the accumulator still panics if one of the inputs to a parent hash function is all 0s
07:12 < adiabat> if that's happening it means there's uninitialized data that's in the tree somehow, so all bets are off and everything's broken
07:13 < adiabat> at that point it seems like there's no meaningful way to recover since everything's broken
07:13 < adiabat> I guess you could return an error there, and cmd would grab it and say "the accumulator is broken"
07:14 < adiabat> but then you have methods like parentHash(r, l) Hash -> parentHash(r, l (Hash, error)
07:15 < adiabat> which means you have to make everything that calls it also return an error... gets annoying, and really, wherever that error ends up
07:15 < adiabat> it's going to end the program, because it's an internal "this program is written wrong" error
07:41 < rjected> Right, I think that specific case in parentHash is one of the cases where a panic is warranted, and it's not exported + isn't a function of a struct so it makes sense
07:54 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
08:56 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #utreexo
09:31 -!- dergoegge [dergoegge@gateway/vpn/nordvpn/dergoegge] has quit [Quit: leaving]
10:00 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
14:27 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #utreexo
14:38 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
20:46 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #utreexo
21:40 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
22:35 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #utreexo
--- Log closed Thu Jun 04 00:00:41 2020