Extract fields from errors

[itamarst]

Fixes #236.

This will allow e.g. including HTTP response code as a field in failed actions due to flocker.restapi._error.BadRequest.

[tomprince]

Have you considered defaulting to extracting .args?

[itamarst]

Hm. We already do repr(exception) for the reason... but that does leave out some info.

[itamarst]

so {"args": safe_repr(exception.args)} as default?

[tomprince]

That was my thought. I haven't looked at examples or anything, to see if it reasonable. Actually, {"args": map(safe_repr, exception.args)} maybe even (typically args is a tuple, so turning into a structured thing would be nice).

[itamarst]

Also occurs to me that eliot:traceback ought to be using this as well.

[wallrj]

❓ Why not use error-handling as the section reference?

[wallrj]

Ah, I see that you get that for free from the title below.
The reference is there purely for linking from the release notes.

[wallrj]

Thanks @itamarst

Looks good. A few points:

1. extractor is spelt extracter in various parts of the code. Needs fixing.
2. looks like there might be a mistake in the SubSubException test.
3. ❓ I don't find the name of the extractor registration function intuitive.
4. ❓ Shouldn't this be more closely tied in with the existing Eliot Types / Fields / serialisation system?
5. ❓ Currently EnvironmentError 's will be logged with their full repr. Will we lose some important messages with the new default extractor?

Please address or answer the points above (including Tom's) and then merge.

[itamarst]

The type system is a tricky one, yeah... Requiring every ActionType to specify every possible exception-extracted field seems unreasonable, seems better to do it on per-exception level.

However, there's still issue with adding these new fields to eliot:traceback since it has a MessageType with fixed fields...

[itamarst]

The type system is to help:

1. Users make sure they generate correct logs.
2. Document what is being generated.

First use case seems irrelevant here, since it's errors coming out of the running system - unexpected results don't mean a bug in logging code. Second use case is still relevant though.

[itamarst]

As far as having default that uses Exception.args... the default __str__ or maybe __repr__ for Exception already shows those. So the information isn't lost, although it is in less structured format. On the other hand I assume most exceptions that rely on that just dump strings in, so doesn't seem like including safe_repr of args by default in addition to safe_repr of the exception instance adds much. We can always add it later.