[Feature] Reverse nested exceptions

[vrobic]

Describe the feature you'd like

When nested exceptions occur, I'd like the last one to be listed in the DataDog Error Tracking, and not the first one.

Scenario

1. An exception is thrown, let's name it A
2. In a try/catch block, exception A is caught and a new exception B is thrown, with exception A as its previous one.

How DataDog handles it

Exception A will be listed in the DataDog Error Tracking as the main error, with B as the next one.

What I was expecting

As a PHP developer and according to PHP native behavior and other tools (including Symfony Profiler), I was expecting the exception B to be the main error, listed in the DataDog Error Tracking, with A as the previous one.

Here is the error.stack span attribute from a real world \PDOException:

In this example, I'd like to see the Symfony\Component\Messenger\Exception\HandlerFailedException listed in the DataDog Error Tracking, with its previous ones, just like this:

Is your feature request related to a problem?

With exception A often being technical (eg. PDOException), and B being something more business oriented (eg. CouldNotSaveInvoiceException), it's difficult for our team to know what is the severity and user frustration of the errors listed in the DataDog Error Tracking.

Every backend developer in our team is from a PHP background and none of them were expecting to see the exception stack reversed.

Describe alternatives you've considered

No response

Additional context

A coworker of mine has found that this behavior is from ddtrace_exception_to_meta function in exception_serialize.c, with the dd_exception_to_error_msg and dd_exception_to_error_type functions being called with the overridden exception variable instead of the exception_root. This piece of code fixes #2498.

I'd like to discuss this with you. @PROFeNoM, as the developer who fixed the issue, can you give us your opinion please?

[bwoebi]

Hey @vrobic - aside from whether it should be changed or not:

The rationale is that a generic Symfony\Component\Messenger\Exception\HandlerFailedException does not say much about the exception. With error tracking in particular our goal is to track root causes. HandlerFailedException is not a root cause, but what happens after all the wrapping.

Also, when looking in the trace viewer - you first check out the root span, which is at a specific endpoint, giving you context (whether it's a critical endpoint or not). And then you see a PDOException - oh it's a database problem! However seeing "CouldNotSaveCartException" on a "/cart/save" endpoint is a bit tautological there, i.e. giving you zero extra information.

But you want to track which high-level types of exceptions are thrown, to easily assess impact. Ultimately I think this is a feature, which should be offered by error tracking, rather than by the tracer itself.

So, I think you are in this case better off with requesting this feature from our support, on the error tracking product.