From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 885BB4696C3 for ; Fri, 17 Apr 2020 03:51:56 +0300 (MSK) References: <9ad134f42e6b11bf030f80d90435aac512db0784.1587058424.git.lvasiliev@tarantool.org> <20200416194835.GA3623@atlas> From: Vladislav Shpilevoy Message-ID: <4ff74326-f83d-599d-fcda-c7d8175c9263@tarantool.org> Date: Fri, 17 Apr 2020 02:51:54 +0200 MIME-Version: 1.0 In-Reply-To: <20200416194835.GA3623@atlas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH V4 4/6] error: add session setting for error type marshaling List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , Leonid Vasiliev , tarantool-patches@dev.tarantool.org Hi! On 16/04/2020 21:48, Konstantin Osipov wrote: > * Leonid Vasiliev [20/04/16 20:45]: >> Errors are encoded as a string when serialized to MessagePack to >> be sent over IProto or when just saved into a buffer via Lua >> modules msgpackffi and msgpack. >> >> That is not very useful on client-side, because most of the error >> metadata is lost: code, type, trace - everything except the >> message. >> >> Next commits are going to dedicate a new MP_EXT type to error >> objects so as everything could be encoded, and on client side it >> would be possible to restore types. >> >> But this is a breaking change in case some users use old >> connectors when work with newer Tarantool instances. So to smooth >> the upgrade there is a new session setting - >> 'error_marshaling_enabled'. >> >> By default it is false. When it is true, all fibers of the given >> session will serialize error objects as MP_EXT. > > I don't understand the point of having an MP_EXT if the same > can be achieved with simply a new messagepack key. There is > already IPROTO_ERROR_CODE, IPROTO_ERROR_MESSAGE, why can't you add > IPROTO_ERROR_TYPE? Seems like you are talking about the case when error object is thrown as an exception. But the patchset is about being able to recognize and decode errors even when they are returned inside response body, as a part of IPROTO_OK response type.