I subscribe to Josh Gray's philosophy of only having another exception class if there is something different to be done when it's caught. For example, if the caller would do the exact same thing for NoPermissionsException and DiskFullException, just use an IOException and be done with it. I also subscribe to the philosophy that a library have its own exception hierarchy (possibly with a single class), which I think meshes with Jake's "exceptions exiting a library to be reasonably limited to exceptions generated by and relating to that library".
Sarge > On 8 Sep, 2017, at 07:19, Jacob Barrett <jbarr...@pivotal.io> wrote: > > Sorry for jumping on this thread so late. This is an important issue we > need to address. > > On Thu, Aug 17, 2017 at 11:57 AM David Kimura <dkim...@pivotal.io> wrote: > >> Using exceptions seems contrary to the Google C++ Style Guide we adopted, >> which states: *"do not use C++ exceptions"* [3 >> <https://google.github.io/styleguide/cppguide.html#Exceptions>]. Here is >> a >> link [4 <https://www.youtube.com/watch?v=NOCElcMcFik#t=30m29s>] to a >> cppcon >> talk defending their decision. Does it make sense to enforce this rule on >> our code base? >> > > I don't agree with this approach, as I always tend towards > progress/modernization, but it was their choice to remain consistent across > their code base. I would say if we made the same decision solely on > consistency then we would have our own exceptions derived from a base > exception class. This is consistent with our Java and .NET as well as > current C++ clients. > > >> If we decide to knowingly ignore this rule, would we want to continue to >> propagate custom exceptions or switch to standard exceptions? At the very >> least, it seems to me that our custom exceptions should derive from their >> most closely matching standard exception counterparts. Thoughts? >> > > I agree with your recommendation of using our exceptions but extend the > most appropriate C++11 exceptions where applicable. I think it is good form > for exceptions exiting a library to be reasonably limited to exceptions > generated by and relating to that library. > > Our current Exception class also brings with it stack tracing, although > poorly supported on some platforms and disabled by default. Boost just > recently graduated a stack track library that is supported on many > compilers and platforms. It may be worth integrating into our exceptions as > a replacement for the current stack tracing code. > > -Jake
