Follow-up from #5602 (PR #5612), recorded in the 26.8.1 release notes as a known limitation.
#5602 gave arithmetic errors - 64-bit overflow, division and modulo by zero - their own type (ArithmeticErrorException) so the wire layers can report them as the client errors Neo4j calls Neo.ClientError.Statement.ArithmeticError rather than as server faults. Two layers were wired:
- HTTP: 400, via
AbstractServerHttpHandler (both the direct arm and the auto-commit TransactionException arm)
- Bolt:
Neo.ClientError.Statement.ArithmeticError, via BoltNetworkExecutor.classifyExecutionError
The other protocol modules - postgresw, mongodbw, redisw, graphql, gremlin - still report it through their generic CommandExecutionException handling. That was the right scope for #5602, whose subject is the two paths a Cypher statement normally arrives on, but it means the 500-vs-400 distinction is not made if a statement reaches the engine another way.
The same asymmetry applies to the other client-error classifications those layers do not model, so this is worth looking at as "how does each wire protocol map ArcadeDB's exception hierarchy" rather than one-exception-at-a-time. CauseChain.find(...) (added by #5612, in com.arcadedb.exception) is available to any module for the cause-chain walk these mappings need - a failure arrives wrapped differently depending on the path, and inspecting only getCause() is what made a doubly-wrapped client error report as a server fault on the CALL path.
Low priority: reaching integer overflow through Postgres or Redis wire syntax is unusual. Filed so the limitation is tracked rather than rediscovered.
Follow-up from #5602 (PR #5612), recorded in the 26.8.1 release notes as a known limitation.
#5602 gave arithmetic errors - 64-bit overflow, division and modulo by zero - their own type (
ArithmeticErrorException) so the wire layers can report them as the client errors Neo4j callsNeo.ClientError.Statement.ArithmeticErrorrather than as server faults. Two layers were wired:AbstractServerHttpHandler(both the direct arm and the auto-commitTransactionExceptionarm)Neo.ClientError.Statement.ArithmeticError, viaBoltNetworkExecutor.classifyExecutionErrorThe other protocol modules -
postgresw,mongodbw,redisw,graphql,gremlin- still report it through their genericCommandExecutionExceptionhandling. That was the right scope for #5602, whose subject is the two paths a Cypher statement normally arrives on, but it means the 500-vs-400 distinction is not made if a statement reaches the engine another way.The same asymmetry applies to the other client-error classifications those layers do not model, so this is worth looking at as "how does each wire protocol map ArcadeDB's exception hierarchy" rather than one-exception-at-a-time.
CauseChain.find(...)(added by #5612, incom.arcadedb.exception) is available to any module for the cause-chain walk these mappings need - a failure arrives wrapped differently depending on the path, and inspecting onlygetCause()is what made a doubly-wrapped client error report as a server fault on theCALLpath.Low priority: reaching integer overflow through Postgres or Redis wire syntax is unusual. Filed so the limitation is tracked rather than rediscovered.