From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tarantool-patches-bounce@freelists.org>
Received: from localhost (localhost [127.0.0.1])
	by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 90AAA231BD
	for <tarantool-patches@freelists.org>; Fri,  9 Aug 2019 15:24:30 -0400 (EDT)
Received: from turing.freelists.org ([127.0.0.1])
	by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id sovBn4BxmeQ9 for <tarantool-patches@freelists.org>;
	Fri,  9 Aug 2019 15:24:30 -0400 (EDT)
Received: from smtp44.i.mail.ru (smtp44.i.mail.ru [94.100.177.104])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 383F1231B4
	for <tarantool-patches@freelists.org>; Fri,  9 Aug 2019 15:24:30 -0400 (EDT)
Subject: [tarantool-patches] Re: [PATCH v1 3/3] box: extend ffi error
 object API
References: <cover.1564657285.git.kshcherbatov@tarantool.org>
 <47d9072e60bdc563c7466a4e51db1a61bc71a610.1564657285.git.kshcherbatov@tarantool.org>
 <55d56797-f937-4088-fdba-7d9dfef51ae6@tarantool.org>
 <20190808233327.sjm76nwf2qhxd4io@tkn_work_nb>
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Message-ID: <33171387-19ef-67d3-88c0-5ee237f7bb77@tarantool.org>
Date: Fri, 9 Aug 2019 21:27:01 +0200
MIME-Version: 1.0
In-Reply-To: <20190808233327.sjm76nwf2qhxd4io@tkn_work_nb>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: tarantool-patches-bounce@freelists.org
Errors-to: tarantool-patches-bounce@freelists.org
Reply-To: tarantool-patches@freelists.org
List-Help: <mailto:ecartis@freelists.org?Subject=help>
List-Unsubscribe: <mailto:tarantool-patches-request@freelists.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: tarantool-patches <tarantool-patches.freelists.org>
List-Subscribe: <mailto:tarantool-patches-request@freelists.org?Subject=subscribe>
List-Owner: <mailto:>
List-post: <mailto:tarantool-patches@freelists.org>
List-Archive: <http://www.freelists.org/archives/tarantool-patches>
To: tarantool-patches@freelists.org, Alexander Turenko <alexander.turenko@tarantool.org>
Cc: Kirill Shcherbatov <kshcherbatov@tarantool.org>, kostja@tarantool.org



On 09/08/2019 01:33, Alexander Turenko wrote:
>>> +box_error_unwrap(box_error_t *error)
>>> +{
>>> +	struct error *reason = error->reason;
>>> +	assert(reason != NULL);
>>> +	diag_set_error(diag_get(), reason);
>>> +	error_unref(reason);
>>> +	error->reason = NULL;
>>> +	return reason;
>>
>> 7. Unwrap does not allow to unwrap a leaf error.
>> But there is no API to determine if the error is
>> leaf. So a user can't determine when to stop calling
>> unwrap.
>>
>> I am talking about C public API which you have changed
>> here. A user can't check error->reason != NULL before
>> calling box_error_unwrap.
>>
>> Moreover, it is inconsistent with Lua version. Lets
>> better return the argument when error->reason == NULL
>> in box_error_unwrap. Then a user of the C API would
>> just unwrap the stack until box_error_unwrap(e) == e.
>> Also it simplifies Lua version implementation.
> 
> Why not just return NULL when there is no a reason? It seems to be more
> logical for me.
> 

Perhaps. I don't mind, NULL is good too. But assertion is
not good.