Improve error handlers #760
Open
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.
Whenever a Postgres error is thrown and capture by our C++ code (or in DuckDB) we were re-throwing a generic
duckdb::EXECUTORfor no specific reason.Instead this PR throws a custom exception that captures the Postgres
ErrorDataobject to be handled by the corresponding C++ exception handler, which will eventually convert it back to a Postgres exception.The resulting errors are much nicer as a result and preserve more information.
We could even add even more logging/tracing details such as which function was wrapped etc. (I was not sure where to put it exactly:
context,detail, orNOTICElog, but trivial to improve).The main drawback of this approach is that we have to serialize the
ErrorDatapointer to make sure that even if DuckDB capture the exception and re-throw with another type we do not loose the Postgres information, but there is no foul-proof way of making sure that the pointer will be valid in the C++ handler.