Support the ERROR type #209

oleg-jukovec · 2022-08-18T14:16:41Z

See the feature description:

https://www.tarantool.io/en/doc/latest/dev_guide/internals/msgpack_extensions/#the-error-type

oleg-jukovec · 2022-11-12T09:28:59Z

We must remember about (if the feature will be implemented after IPROTO_ID, #226 ):

https://github.com/tarantool/tarantool/blob/0c3246decf34d4530c46dbaba4cb303b808791ba/src/box/lua/call.c#L84-L93

Since 2.4.1 IPROTO_ERROR (0x31) is renamed to IPROTO_ERROR_24 and IPROTO_ERROR name is used for 0x52 constant describing extended error info [1]. 1. https://www.tarantool.io/en/doc/latest/dev_guide/internals/msgpack_extensions/#the-error-type Part of #209

Since Tarantool 2.4.1, iproto error responses contain extra info with backtrace [1]. After this patch, Error would contain ExtraInfo field (BoxError object), if it was provided. 1. https://www.tarantool.io/en/doc/latest/dev_guide/internals/box_protocol/#responses-for-errors Part of #209

Since 2.4.1 IPROTO_ERROR (0x31) is renamed to IPROTO_ERROR_24 and IPROTO_ERROR name is used for 0x52 constant describing extended error info [1]. 1. https://www.tarantool.io/en/doc/latest/dev_guide/internals/msgpack_extensions/#the-error-type Part of #209

Since Tarantool 2.4.1, iproto error responses contain extra info with backtrace [1]. After this patch, Error would contain ExtraInfo field (BoxError object), if it was provided. 1. https://www.tarantool.io/en/doc/latest/dev_guide/internals/box_protocol/#responses-for-errors Part of #209

Since Tarantool 2.4.1, iproto error responses contain extended info with backtrace [1]. After this patch, Error would contain ExtendedInfo field (BoxError object), if it was provided. Error() handle now will print extended info, if possible. 1. https://www.tarantool.io/en/doc/latest/dev_guide/internals/box_protocol/#responses-for-errors Part of #209

Tarantool supports error extension type since version 2.4.1 [1], encoding was introduced in Tarantool 2.10.0 [2]. This patch introduces the support of Tarantool error extension type in msgpack decoders and encoders. Tarantool error extension type objects are decoded to `*tarantool.BoxError` type. `*tarantool.BoxError` may be encoded to Tarantool error extension type objects. Error extension type internals are the same as errors extended information: the only difference is that extra information is encoded as a separate error dictionary field and error extension type objects are encoded as MessagePack extension type objects. The only way to receive an error extension type object from Tarantool is to receive an explicitly built `box.error` object: either from `return box.error.new(...)` or a tuple with it. All errors raised within Tarantool (including those raised with `box.error(...)`) are encoded based on the same rules as simple errors due to backward compatibility. It is possible to create error extension type objects with Go code, but it not likely to be really useful since most of their fields is computed on error initialization on the server side (even for custom error types). This patch also adds ErrorExtensionFeature flag to client protocol features list. Without this flag, all `box.error` object sent over iproto are encoded to string. We behave like Tarantool `net.box` here: if we support the feature, we provide the feature flag. 1. tarantool/tarantool#4398 2. tarantool/tarantool#6433 Closes #209

Tarantool supports error extension type since version 2.4.1 [1], encoding was introduced in Tarantool 2.10.0 [2]. This patch introduces the support of Tarantool error extension type in msgpack decoders and encoders. Tarantool error extension type objects are decoded to `*tarantool.BoxError` type. `*tarantool.BoxError` may be encoded to Tarantool error extension type objects. Error extension type internals are the same as errors extended information: the only difference is that extra information is encoded as a separate error dictionary field and error extension type objects are encoded as MessagePack extension type objects. The only way to receive an error extension type object from Tarantool is to receive an explicitly built `box.error` object: either from `return box.error.new(...)` or a tuple with it. All errors raised within Tarantool (including those raised with `box.error(...)`) are encoded based on the same rules as simple errors due to backward compatibility. It is possible to create error extension type objects with Go code, but it not likely to be really useful since most of their fields is computed on error initialization on the server side (even for custom error types). This patch also adds ErrorExtensionFeature flag to client protocol features list. Without this flag, all `box.error` object sent over iproto are encoded to string. We behave like Tarantool `net.box` here: if we support the feature, we provide the feature flag. Since it may become too complicated to enable/disable feature flag through import, error extension type is available as a part of the base package, in contrary to Decimal, UUID, Datetime and Interval types which are enabled by importing underscore subpackage. 1. tarantool/tarantool#4398 2. tarantool/tarantool#6433 Closes #209