You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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#6433Closes#209
0 commit comments