Nested/chained error API

[ArtDu]

Reason

For a better understanding of where the error occurred, it is desirable to have some kind of interface where you could get a nested error. A specific example of use can be found here tarantool/crud#186.

It will be inconvenient to catch errors if there is a high level of nesting. For example (vshard -> crud -> cartridge-java -> client-app) each of these api can throw an error, catch it and generate a new one, so it will be difficult to find out what the original error was.

Examples from other languages

The functionality of nested/chained errors is implemented in other languages:

1. Java

catch(IOException e) {
  throw new ApplicationException("Failed on reading file soandso", e);
  //                              ^ Message                        ^ Cause
}
...
// then when we catch error, we can get cause
catch(ApplicationException e) {
  e.getCause()
  ...
}

2. Python 3

try:
    v = {}['a']
except KeyError as e:
    raise ValueError('failed') from e

# then when we catch error, we can get cause
except ValueError as e:
    e.__cause__

[olegrok]

Perhaps this is the time for advertising.

Because Tarantool core since 2.4 support something similar.

tarantool> e = box.error.new('MyErrorType', 'Message')
---
...

tarantool> error(e)
---
- error: Message
...

tarantool> e.type
---
- MyErrorType
...

tarantool> e.trace
---
- - file: '[string "e = box.error.new(''MyErrorType'', ''Message'')"]'
    line: 1
...

Also such errors could be stacked:

tarantool> reason = box.error.new('MyErrorType', 'Reason')
---
...

tarantool> e:set_prev(reason)
---
...

tarantool> e.prev
---
- Reason
...

tarantool> e.prev.prev
---
- null
...

[kyukhin]

Not planned.

[Totktonada]

From the triage meeting: there are some plans to dramatically improve error framework in tarantool. @unera knows more.