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 18F7A272ED for ; Wed, 28 Aug 2019 05:26:13 -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 fDyLG1zW4m6j for ; Wed, 28 Aug 2019 05:26:12 -0400 (EDT) Received: from smtp48.i.mail.ru (smtp48.i.mail.ru [94.100.177.108]) (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 46517272E4 for ; Wed, 28 Aug 2019 05:26:12 -0400 (EDT) Date: Wed, 28 Aug 2019 12:26:07 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH v2 3/3] box: introduce stacked diagnostic area Message-ID: <20190828092607.GA19848@atlas> References: <20190826223423.GC1189@atlas> <20190826232322.rnljbredguexfppr@tkn_work_nb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190826232322.rnljbredguexfppr@tkn_work_nb> 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: Alexander Turenko Cc: Kirill Shcherbatov , tarantool-patches@freelists.org, georgy@tarantool.org * Alexander Turenko [19/08/27 09:50]: > > > + * 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. You try to do some useful work and get an error. You unwind, and get another one during cleanup. -- Konstantin Osipov, Moscow, Russia