Open emicks opened 3 years ago
@mwringler and team: Do we have any feedback on this regarding the topic at hand? Do we want to adjust here something in terms of next beta release?
Personally, I think extending RuntimeException
instead of PropelException
is correct here, since the wrapped exceptions that lead to the QueryExecutionException
are not caused by Propel, but by the underlying DB connection. But I don't mind changing it back.
I am facing a bc break introduced with the refactoring in #1747. As far as I can see,
Criteria::handleStatementException()
in the original code always throws aPropelException
, while the refactored code throws aQueryExecutionException
(aRuntimeException
). So now when I catch aPropelException
in the calling code, I don't catch theQueryExecutionException
. Perhaps inheritingQueryExecutionException
fromPropelException
is a feasible way to solve this issue.