Enables metadata in exceptions, adds some metadata to CastErrors

[akariv]

Exceptions in tableschema contain very little info on the reason for the exception (apart from a text message).
For automated processing we want to know more on the source of the error.
I've made a simple change which adds generic metadata to the tableschema exceptions, and added such metadata to CastErrors sent around the library.

This shouldn't create any compatibility issues with existing code.

[roll]

@akariv
Thanks. I also always expected that we would extend our Error API. Just a few concerns regarding the exact proposal and also similar frictionlessdata/tableschema-js#147:

• extending Error we expose kinda massive new API and I think our intention should be to make it less vulnerable for getting out-of-control
• we have https://github.com/frictionlessdata/data-quality-spec/blob/master/spec.json to comply with when it's possible

So regarding this PR I'm wondering why don't we just expose:

• error.schema (Schema/None)
• error.field (Field/None)
• error.row (Row/None)
• etc

I mean the already existent API which could be present for error or not (depending on an error context). In this case we don't need additionally e.g. document that medata have field.name key. We just need to link the Field API documentation.

And about naming:

• duplicate_row - in Data Quality Spec (we follow it for a lot of Py/Js software) e.g. this one will be duplicate_row_number
• etc

WDYT?

[roll]

For a reference, we already have slightly extended error API for Javascript - https://github.com/frictionlessdata/tableschema-js#errors

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.