On Thu, 20 Sep 2018 at 03:39, John Floren <j...@jfloren.net> wrote:
> What's the right way to handle this? Write our own bufio that lets us
> reset the error and io.Writer while preserving unwritten data?
>
I'm not sure there is "one right way", but one possibility is to push the
reliability layer one level down:
var relW io.Writer = NewReliableConnection(wifiW)
bufW := bufio.NewWriter(relW)
go func () {
for statusChange := range relW.StatusChanges {
log.Println("WiFi connection state change!", statusChange)
}
}()
// It can be arranged that this will only receive an error if the
underlying write error is unrecoverable.
_, err := io.Copy(bufW, theDataSource)
etc.
ReliableConnection's Write method can contain all of the logic relating to
masking errors and reconnecting, and the buffering logic doesn't have to
care.
With this approach the unreliability of the wifiW is transparent to the
client code (doing the writing), so it doesn't need to know anything about
how to resume writing from the 'correct' offset or anything like this.
Another thought about bufio's current sticky error behaviour is that this
is very useful for consolidating error handling. You can do a series of
cheap writes without checking errors, and then do a flush and check the
error once at the end. The only 'loss' is the performance cost of the
subsequent writes after the first error, if they are significant.
--
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.
For more options, visit https://groups.google.com/d/optout.
