According to the docs for “Handling Data Conflicts” a custom conflict resolver can throw exceptions to abort conflict resolution:
If there is an exception thrown in the resolve() method, the exception will be caught and handled:
- The conflict to resolve will be skipped. The pending conflicted documents will be resolved when the replicator is restarted.
The CBL C SDK primarily exposes a C API and C doesn’t have exceptions. Internally, C++ exceptions are caught and have the effect of aborting conflict resolution, but CBL C is not always used with C++. C++ exceptions can also be tricky when thrown between library boundaries because the C++ standard libraries used in the different libraries/executables have to be compatible.
I believe the CBL C SDK should provide a way for the custom conflict resolver to signal that it is aborting without C++ exceptions.
I think the message there is not “throw exceptions to stop resolution.” but rather “in the event that you inadvertently cause an exception it is not going to bring down the whole process.” Stopping conflict resolution is not something that should be a normal part of operation, because the rule in 2.0 and above is that conflicts must be resolved (as opposed to 1.x where they could just sit in a state of conflict and slowly collect). Given that, I am not sure that I can get on board with giving an official way to do this thing that shouldn’t be done. When a conflict resolution is incomplete, it hampers replicator progress because the replicator must retry that document over and over again. There are only a few valid outcomes from pulling a document.
- Insertion without conflict
- Insertion after conflict resolution
- Filter rejection
Other outcomes are considered errors (including failed conflict resolution, which leaves nothing available to save into the database). @pasin should chime in here as well though.
Thank you for your answer. I generally agree with you that good APIs don’t encourage problematic uses. The C SDK is a bit special though because it can be used to build APIs in higher level languages, e.g. Python, JavaScript or in my case Dart. These upper layers need a way to communicate to the C SDK that the conflict resolver written in the high-level language threw an exception. Not because users are encouraged to abort conflict resolution, but so that these users can monitor their logs and correct their custom resolver.
That is a fair point, I’ll bring it up internally for discussion on what to do about it.