From: Vasilij Schneidermann <mail@vasilij.de>
To: Visuwesh <visuweshm@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, 67142@debbugs.gnu.org
Subject: bug#67142: 29.1; with-sqlite-transaction commits on exception rather than rolling back
Date: Fri, 17 Nov 2023 10:08:36 +0100 [thread overview]
Message-ID: <ZVctlEp8McWMG2CN@odonien.localdomain> (raw)
In-Reply-To: <87a5rc4vwy.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 981 bytes --]
> > I don't understand this part, sorry. Why do we need a symbol to
> > return the result of the body?
>
> db-var and func-var are uninterned symbols in the macro expansion but
> the variables 'result' and 'commit' marked below aren't. If the intent
> is not to expose these variables to the macro's BODY, the inner let
> should also uninterned symbols right?
Correct, this is what I was hinting at. As annoying as it is, when
writing unhygienic macros one should use uninterned symbols to avoid
exposing additional variables to the BODY argument.
Alternatively, the pattern of `(let ((return (...))) ... return)` can be
replaced with `(prog1 (...) ...)`.
@Eli: The new patch looks better and closer to how the issue is solved
in the Ruby sqlite3 gem. I'm still not sure about this use of
`unwind-protect` being correct, but it does preserve the backtrace in
case of an error better than when I used `(condition-case e (...) (error
(apply #'signal e)))`.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-11-17 9:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 0:47 bug#67142: 29.1; with-sqlite-transaction commits on exception rather than rolling back Vasilij Schneidermann
2023-11-16 14:12 ` Eli Zaretskii
2023-11-16 20:25 ` Vasilij Schneidermann
2023-11-17 7:48 ` Eli Zaretskii
2023-11-17 8:38 ` Visuwesh
2023-11-17 9:08 ` Vasilij Schneidermann [this message]
2023-11-18 10:37 ` Eli Zaretskii
2023-11-20 21:14 ` Vasilij Schneidermann
2023-11-21 13:39 ` Eli Zaretskii
2024-03-03 14:04 ` J.P.
2024-03-11 3:43 ` J.P.
2024-03-11 13:25 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZVctlEp8McWMG2CN@odonien.localdomain \
--to=mail@vasilij.de \
--cc=67142@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=visuweshm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.