geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Barrett <jbarr...@pivotal.io>
Subject Re: [DISCUSS] geode-native c++ exceptions
Date Fri, 08 Sep 2017 14:19:03 GMT
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 <dkimura@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message