[
https://issues.apache.org/jira/browse/GEODE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17408794#comment-17408794
]
ASF GitHub Bot commented on GEODE-9559:
---------------------------------------
mmartell commented on a change in pull request #862:
URL: https://github.com/apache/geode-native/pull/862#discussion_r701045992
##########
File path: clicache/src/Cache.cpp
##########
@@ -215,12 +233,18 @@ namespace Apache
GC::KeepAlive(m_nativeptr);
}
- _GF_MG_EXCEPTION_CATCH_ALL2
+ }
+ catch (const apache::geode::client::Exception& ex) {
+ throw Apache::Geode::Client::GeodeException::Get(ex);
+ }
+ catch (System::AccessViolationException^ ex) {
Review comment:
Interesting question that deserves some thought. AccessViolations are
baaaad. So you don't want to just eat them. OK, good, we don't. We rethrow
them. But why catch them in the first place?
The only thing I can come up with is to help track down bugs in our code. We
catch/rethrow AccessViolations all over the place (212 places), so it allows
setting breakpoints which can be caught in the debugger so we can look around.
This may have been useful early on, but I doubt it provides any value now.
I'm good with removing: catch (System::AccessVilationException) everywhere.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Demacroize clicache
> --------------------
>
> Key: GEODE-9559
> URL: https://issues.apache.org/jira/browse/GEODE-9559
> Project: Geode
> Issue Type: Improvement
> Components: native client
> Reporter: Michael Martell
> Priority: Major
> Labels: pull-request-available
>
> Macros in C++ complicate debug efforts and code maintenance and are generally
> considered old school ([https://stroustrup.com/icsm-2012-demacro.pdf).] This
> PR is to remove all the complicated macros in the .NET Framework client, e.g.
> the clicache module.
> In addition to improving the maintainability of the clicache module, removing
> the macros will greatly assist the creation of the .NET Core client. [dotPeek
> |http://jetbrains.com/decompiler/] is proving to be a valuable tool in the
> .NET Core project, but is currently limited by the extensive use of macros in
> the clicache code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
