Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prevent throw in destructor #1511

Merged
merged 2 commits into from Jan 24, 2019

Conversation

Projects
4 participants
@jmjatlanta
Copy link
Contributor

commented Jan 2, 2019

This is an improvement for Issue #1246.

PR #1510 lowered the number of warnings, but did not eliminate the cause.

I created this PR as an adjunct to #1510 so that we can determine the goods and bads of this approach. I look forward to your comments.

jmjatlanta added some commits Jan 2, 2019

@jmjatlanta jmjatlanta referenced this pull request Jan 18, 2019

Merged

Fix compiler warnings #1510

@oxarbitrage

This comment has been minimized.

Copy link
Member

commented Jan 19, 2019

I think this is good together with #1510

In order to merge and clean a bit commit history i think we can close this one and #1510 in favor of a new pull with just 3 commits or similar:

  • move session() definition to cpp.
  • prevent throw in destructor.
  • signed/unsigned.
}
return;
} catch (fc::exception& ex) {
BOOST_FAIL( ex.to_detail_string() );

This comment has been minimized.

Copy link
@pmconrad

pmconrad Jan 20, 2019

Contributor

Admittedly CAPTURE_AND_RETHROW seems pointless if it doesn't capture anything. Perhaps LOG_AND_RETHROW instead? Or why do you BOOST_FAIL on fc::exception only is better? (Note that fc macros also catch and handle other exceptions.)

@pmconrad

This comment has been minimized.

Copy link
Contributor

commented Jan 20, 2019

I wouldn't call this a "true fix" because the end result is still an unclean application exit on library error.

@jmjatlanta

This comment has been minimized.

Copy link
Contributor Author

commented Jan 22, 2019

I wouldn't call this a "true fix" ...

I changed it to "an improvement" to be more accurate. A "true fix" may be

  • swallowing the exceptions thrown in the destructor (not a good idea)
  • only calling methods that do not throw exceptions (not possible without the option below)
  • call a "shutdown" method before destruction (error prone)

None of these sound good to me. I am open to suggestions.

@jmjatlanta jmjatlanta merged commit f2a0b4d into jmj_1246 Jan 24, 2019

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@abitmore abitmore deleted the jmj_1246b branch Feb 5, 2019

@abitmore abitmore added this to In progress in Feature Release (201902) via automation Feb 5, 2019

@abitmore abitmore added this to the 201902 - Feature Release milestone Feb 5, 2019

@jmjatlanta jmjatlanta moved this from In progress to Done in Feature Release (201902) Feb 5, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.