I think that it would be best to abide by using the std::exception as the base. I think it brings with it all the language support and flexibility. There are a few penalties obviously to using std::exception as a base, but I think they are sufficiently offset by using a standard. As far as the number of exceptions, I believe in the philosophy of using as few as possible and using inheritance to drive specificity. The benefit is that the code can be as simple or as complex as it can be without unnecessary overhead e.g error => network error => tcp error. So, I may just care there is a network error and the being able to tell if something derives from network error is perfect.
Thanks, Mark > On Sep 8, 2017, at 1:35 PM, Ernest Burghardt <eburgha...@pivotal.io> wrote: > > 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 >> >>
