From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6A21128676 for ; Mon, 26 Aug 2019 19:23:40 -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 pIzM9fcxfpE1 for ; Mon, 26 Aug 2019 19:23:40 -0400 (EDT) Received: from smtp18.mail.ru (smtp18.mail.ru [94.100.176.155]) (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 2A79528648 for ; Mon, 26 Aug 2019 19:23:40 -0400 (EDT) Date: Tue, 27 Aug 2019 02:23:22 +0300 From: Alexander Turenko Subject: [tarantool-patches] Re: [PATCH v2 3/3] box: introduce stacked diagnostic area Message-ID: <20190826232322.rnljbredguexfppr@tkn_work_nb> References: <20190826223423.GC1189@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190826223423.GC1189@atlas> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Konstantin Osipov Cc: Kirill Shcherbatov , tarantool-patches@freelists.org, georgy@tarantool.org > > + * Remove all errors set in a given diagnostics area after a > > + * given savepoint. > > + * > > + * Operation removes reason for the error > > + * preceding the savepoint and releases a diagnostic area's > > + * reference on the most recent error (diag::last for the > > + * rollback beginning). This means that if user code have a > > + * pointer and have a reference to an error object from the > > + * rollback zone, this pointer and the following "reason" error > > + * objects are a valid error list. > > + */ > > BTW, did you check if anyone likes the name 'reason'? I'm not very > fond of it, previous error is not always the reason of the current > one. I would simply call it 'prev' or 'next'. Can you give an example of the error that definitely should be previous for another one, but is not its reason? It is so for warnings, but this is possibly because they just should not be mixed with errors within one stack. WBR, Alexander Turenko.