We are following the google style guide which prohibits exceptions [1]. Several places in our code we use std::vector and std::make_shared which can potentially throw std::bad_alloc exceptions that we don't currently wrap in try/catch blocks. These classes/objects are used for constructing/manipulating metadata (all errors for allocations of data are checked and returned via Status objects).
In general, it seems unlikely that these code paths would get triggered, but there is still a possibility. Does anybody have any thoughts on how thorough we want to be about avoiding these types of edge cases? My thought is to leave the code as is and accept the small chance that these get hit. The main rationale is that if these types of calls do raise std::bad_alloc, it is highly likely that the program using the Arrow library is likely in an unstable state already (most of the allocations should be less then 100 bytes or so). A second point is that a cursory search of Kudu [2] and Impala [3] code bases (both of which also intend to follow the style guide) turn up some similar calls that could throw std::bad_alloc (it is possible there is some other magic happening here to avoid these). This isn't completely satisfying though, so I'm happy to be convinced otherwise. Thanks, -Micah [1] https://google.github.io/styleguide/cppguide.html#Exceptions [2] https://github.com/cloudera/kudu/blob/7f3691a826b9d27199319409f8d721ec1d08a8ba/src/kudu/consensus/log_reader.cc#L74 [3] https://github.com/cloudera/Impala/blob/a36dcfc0322e213c06d6cf8d3f330c4b06739523/be/src/common/object-pool.h
