Error handling merge #41
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
This time focussing mainly on reporting memory allocation errors with exceptions rather than return values.
Conflicts: test/transactions.cpp
Conflicts: src/tightdb/array.cpp src/tightdb/array.hpp src/tightdb/column.cpp src/tightdb/column.hpp src/tightdb/column_binary.hpp src/tightdb/column_mixed.cpp src/tightdb/column_string.hpp src/tightdb/column_tpl.hpp src/tightdb/table_ref.hpp
Conflicts: TightDB.vcxproj.filters
Conflicts: TightDB.vcxproj.filters
|
This one is ready for your review. |
|
+1 |
| { | ||
| const Table* subtab = t->get_subtable_ptr(column_ndx, row_ndx); | ||
| subtab->bind_ref(); | ||
| return subtab; | ||
| } | ||
|
|
||
| inline Table* LangBindHelper::get_subtable_ptr_during_insert(Table* t, size_t col_ndx, size_t row_ndx) { |
There was a problem hiding this comment.
Don't just remove this - get_subtable_ptr_during_insert() is used in java-binding.
There was a problem hiding this comment.
It's not removed, just moved to cpp-file.
|
In general, please follow our agreed coding standard wrt. if/else statements: The statements after 'if' or 'else' must be on a seperate line: |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Next phase of error handling.
This time focusing mainly on reporting memory allocation errors with exceptions rather than return values.
Also introducing TIGHTDB_OVERRIDE - (a substitute for C++11 'override')
http://en.wikipedia.org/wiki/C%2B%2B11#Explicit_overrides_and_final
I'm using two kinds of markings to help manage exception safety:
void foo() TIGHTDB_NOEXCEPT - to mark a function that can never throw. Such a function really must never throw, so in general it must not call any function or operator that is not itself marked with TIGHTDB_NOEXCEPT. It requires some care to ensure that this constraint is maintained.
The more functions are marked with TIGHTDB_NOEXCEPT, the easier it will be to ensure that our code behaves appropriately when exceptions are unrolling the call stack.
To indicate where exceptions can emanate from, I use the following notation. I have only added it in places where I am sure the function is really supposed to be allowed to throw.
I am in no way done with this process of exception marking. Two function that I would be particularly interesting in marking non-throwing, are Allocator::Free() and Table::~Table().
/cc @rrrlasse @astigsen @bmunkholm