zeroshade commented on a change in pull request #9862:
URL: https://github.com/apache/arrow/pull/9862#discussion_r606825797
##########
File path: go/arrow/ipc/file_reader.go
##########
@@ -348,10 +356,26 @@ func (src *ipcSource) buffer(i int) *memory.Buffer {
return memory.NewBufferBytes(nil)
}
- raw := make([]byte, buf.Length())
- _, err := src.r.ReadAt(raw, buf.Offset())
- if err != nil {
- panic(err)
+ var raw []byte
+ if src.codec == nil {
+ raw = make([]byte, buf.Length())
+ _, err := src.r.ReadAt(raw, buf.Offset())
+ if err != nil {
+ panic(err)
Review comment:
`panic` is relatively equivalent to throwing an exception in C++ code.
You can recover from a panic just like you could catch a thrown exception in
C++ code. The "general" advice between returning an error vs throwing a panic
is whether or not the error happened during *normal* operation or happened due
to something being coded/programmed incorrectly (like a pre/post-condition
being violated etc.)
As i mentioned, normally *I* would probably return the error here rather
than panic, but I was maintaining the current pattern that existed in the code
rather than creating a breaking change which would make consumers have to
update their call-sites to handle the extra error out param.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
