The sample code is pretty interesting from a return value vs exception perspective: despite being forced to look at return values, the code still silently ignores all errors
I think the best thing to do would be to send a message to an error channel before returning. I'll add that.
For what it's worth I don't think exceptions would help here -- this is the top level function of a goroutine. That means there's no other function that's going to catch any exception that might be thrown (or error that might be returned) from this function.
yeah, that's even more interesting that because its inside a goroutine, there would be nothing to catch it. in this case, i think erlang got some things right with process linking
bencode serialization is 800 lines!? I wrote under 50 in Smalltalk. In fact, I think it was less than half that. (To be fair, you can do this by adding recursive methods to Streams, which already have infrastructure to deal with the external environment.)
A go bencode serialization library could be smaller if it just serialized the bencode data to and from a generic dictionary container. I think another go BitTorrent client, gobit, takes this approach.
But it's convenient to be able to serialize arbitrary application types. That makes the bencode library larger because of the need to use go's reflection APIs to analyze and access the application types. Go's reflection APIs are pretty verbose, which is why the line count is so high.
To make things even more complicated, the BitTorrent protocol has a funny "compute-the-sha1-of-the-info-dictionary" requirement that forces BitTorrent clients to parse that particular part of the BitTorrent protocol using a generic parser.
So in the end, the go bencode serializer supports both a generic dictionary parser and an application type parser, which makes it even larger.
5 comments
[ 3.0 ms ] story [ 26.4 ms ] threadI think the best thing to do would be to send a message to an error channel before returning. I'll add that.
For what it's worth I don't think exceptions would help here -- this is the top level function of a goroutine. That means there's no other function that's going to catch any exception that might be thrown (or error that might be returned) from this function.
yeah, that's even more interesting that because its inside a goroutine, there would be nothing to catch it. in this case, i think erlang got some things right with process linking
But it's convenient to be able to serialize arbitrary application types. That makes the bencode library larger because of the need to use go's reflection APIs to analyze and access the application types. Go's reflection APIs are pretty verbose, which is why the line count is so high.
To make things even more complicated, the BitTorrent protocol has a funny "compute-the-sha1-of-the-info-dictionary" requirement that forces BitTorrent clients to parse that particular part of the BitTorrent protocol using a generic parser.
So in the end, the go bencode serializer supports both a generic dictionary parser and an application type parser, which makes it even larger.