Support chained exceptions

[dcramer]

The proposed interface (from an API perspective):

{
    'exception': [
        {'type': ..., 'value': ..., 'stacktrace': ...},
        {'type': ..., 'value': ..., 'stacktrace': ...},
    ],
}

The order of exceptions implies causation where the first exception was caused by the second, etc..

The checksum would only be calculated from the first exception.

See also:

getsentry/sentry-java#43
http://stackoverflow.com/questions/7553002/example-of-chained-exceptions-stack
http://www.python.org/dev/peps/pep-3134/

[dcramer]

Chaining (dep graph) is complicated from a static analysis standpoint, so what I'm thinking is an ordered list like this:

[
  Exception(..., stack=...),
  Exception(..., stack=...),
  Exception(..., stack=...),
]

[dcramer]

I'm going to propose we do this (backwards incompatible for clients):

{
    'exception': [
        {'type': ..., 'value': ..., 'stacktrace': ...},
        {'type': ..., 'value': ..., 'stacktrace': ...},
    ],
}

This internally would use the aliases feature and would map to a compatible interface that just supported composite ordered exceptions.

The alternative is recursion, and I hate recursion, so we'd make the assumption that the order means that the previous exception is the cause of the next exception.

[ColinHebert]

That seems good.

I'm not familiar with the sentry code, but regarding backward compatibility, wouldn't it be possible to use the exact same system as before with just the possibility for exception to contain either a single object or a list of objects?
And if it is, wouldn't it be also possible if there is an exception and a stacktrace (provided as two independent objects) to assign automatically that stacktrace to the exception? That would probably require some not-so-good-looking code though.

If backward compatibility isn't a priority, I think that renaming exception in exceptions would make more sense.

---

An other question on how the hash would be generated. Would it work only use the first stacktrace (it's what was proposed in getsentry/sentry-java#44 ) or each stacktrace?

[dcramer]

@ColinHebert I haven't really considered which hash would be used, but I think just using the first exception makes sense

Regarding backwards compatibility, we wouldn't be able to accept the new client on the old Sentry either way (since it'd complain about the value not being correct), so I don't think it's something thats solvable/we will have to worry about too much.

[ColinHebert]

@dcramer Fair enough, I think that's a good solution. I can't wait for it to be ready 👍

[dcramer]

Closing this out as the feature works. We can improve it in follow-up changes.