if we continue the merging of Jake <> Sarge comments we might find that std::exception(s) is sufficient if the many name exceptions that pertain to the Library are all handled in a similar manner and only have unique names for human readability, but not a functional consideration...
EB On Fri, Sep 8, 2017 at 8:52 AM, Michael William Dodge <mdo...@pivotal.io> wrote: > 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 > >
