Using API assertions and converting them in SWIG #373
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…rrors For now we don't want to core dump any situation regarding API assertions or runtime errors, therefore converting them to standard SWIG runtime errors. Note: it seems currently there is no easy way how to define this exception handling globally with overriding/adjusting additional handlers in specific files.
Tests for throwing goal resolving problems and move them to a separate test file.
Switch to using API assertions for unsupported arguments in order to don't kill the process when using Python bindings.
Switch to API assertion exceptions when using the `libdnf::Option` methods incorrectly.
Switch to using API assertion when checking any existing `GlobalLogger` instance in ctor.
Switch to using API assertions on API method `load_extra_system_repo`.
1b73363 to
d0b7bc7
Compare
|
Thanks a lot, LGTM. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Try to use API assertions wherever it makes sense and for bindings translate those to standard SWIG runtime exceptions. All usages should be supported by unit tests.
Note: like I've written in some previous SWIG-related PR, it would be nice to have a better solution translating those exceptions on the level where they are actually thrown. Now all methods in generated bindings have their own try-catch blocks.
Closes #345.