Re: [DISCUSS] geode-native c++ exceptions

Ok, I feel like we are all on the same page now, right? As reasonably possible throw library specific exceptions from all public methods. No exception should directly extend any non-library exception, like std exceptions. All Exceptions shall not use multi-inheritance. All exceptions should rea

Re: [DISCUSS] geode-native c++ exceptions

+1 for avoiding multiple inheritance > On 14 Sep, 2017, at 14:23, Ernest Burghardt wrote: > > Sounds like the proposal currently stands to avoid the DiamondOfDeath or > TriangleOfLove that multiple inheritance brings us > and just have the base Exception class inherit std::exception and exte

Re: [DISCUSS] geode-native c++ exceptions

Sounds like the proposal currently stands to avoid the DiamondOfDeath or TriangleOfLove that multiple inheritance brings us and just have the base Exception class inherit std::exception and extend Exception class as appropriate within the library. +1 and thanks for the code examples, very ill

Re: [DISCUSS] geode-native c++ exceptions

The problem stems from the fact that none of the std exceptions virtually inherit from std::exception so you end up in the inheritance triangle of love. I say we avoid the multiple inheritance issues with exceptions by avoiding multiple inheritance altogether in exceptions. See this example. http:/

Re: [DISCUSS] geode-native c++ exceptions

Let me see if I can considerate the consensus here: As reasonably possible throw library specific exceptions from all public methods. As reasonably possible those exceptions should extend C++11 standard library exceptions. All exceptions should extend less specific but logically relevant base ex

Re: [DISCUSS] geode-native c++ exceptions

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 n

Re: [DISCUSS] geode-native c++ exceptions

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, Se

Re: [DISCUSS] geode-native c++ exceptions

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

Re: [DISCUSS] geode-native c++ exceptions

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 wrote: > Using exceptions seems contrary to the Google C++ Style Guide we adopted, > which states: *"do not use C++ exceptions"* [3 >