On Wednesday, 15 June 2022 at 03:09:56 UTC, Steven Schveighoffer wrote:

Sometimes it is not easy to explain why code "feels" wrong and in the case of

       scope(success) conn.exec("COMMIT");

it was not that clear to me some days ago. The reason why I would not write
it is: conn.exec("COMMIT") may throw! Think of deferred constraints which are checked not before the commit. But "[a] [...] scope(success) statement may not exit with a throw [...]" [1]

[1] https://dlang.org/spec/statement.html#ScopeGuardStatement

On 6/15/22 3:51 PM, kdevel wrote:

        scope(success) conn.exec("COMMIT");

I do depend on the commit (and the rollback) not throwing. I probably should swallow any exceptions at that point, and close the connection.

It has not harmed my code though. I tried throwing inside a scope guard, and it.... just works, I'm not sure why you can't throw in those?

I've been meaning to add a reentrant transaction system to mysql-native, because I hate that I can't do nested transactions. That would solve that problem and this problem, by giving me a nothrow function to call in the scope guard.

-Steve

On Wednesday, 15 June 2022 at 20:46:56 UTC, Steven Schveighoffer wrote:

You can but that is not acceptable for the spec explicitly forbids that:

https://dlang.org/spec/statement.html#scope-guard-statement

Quote (again): "A [...] scope(success) statement may not exit with a throw [...]."

Furthermore I always thought of scope guards as a means for cleanup. Cleanup implies in my eyes removing things which have been used in a previous task. This intended use is documented here:

https://tour.dlang.org/tour/en/gems/scope-guards

Using scope guards makes code much cleaner and allows resource allocation
and clean up code to be placed next to each other. These little helpers also
improve safety because they make sure certain cleanup code is always called
independent of which paths are actually taken at runtime.

Performing a COMMIT is rather the opposite of cleanup: It makes (writes) changes to the database persistent.

On Thursday, 16 June 2022 at 10:07:23 UTC, kdevel wrote:

Using scope guards makes code much cleaner and allows resource allocation
and clean up code to be placed next to each other. These little helpers also
improve safety because they make sure certain cleanup code is always called
independent of which paths are actually taken at runtime.

If the spec forbids it, but the compiler allows it, wouldn't it then be a bug?

On Thursday, 16 June 2022 at 11:28:32 UTC, bauss wrote:
[...]

What does "it" referer to? The code, throwing in scope guard? The spec? The compiler? [yes, no, no]

On Thursday, 16 June 2022 at 11:38:40 UTC, kdevel wrote:

Throwing in a scope guard.

On 6/16/22 6:07 AM, kdevel wrote:

I know. I'm not saying it's valid, I'm wondering why it's not valid, since it's trivial for the compiler to detect that code might throw (yet doesn't in this case), and the construct it lowers to (the finally clause) allows throwing.

Note that the finally clause has all the same restrictions as scope(exit) and scope(success) except throwing. It might be an oversight in the spec.

Semantically, you are just not undoing (rollback) the previous steps. How it's implemented in the database is up to them.

-Steve

On Thursday, 16 June 2022 at 13:54:52 UTC, Steven Schveighoffer wrote:

[scope (success) lowered to finally]

[...]

Objection! Not doing a rollback is not the same as doing a COMMIT. Even not "semantically". Until the COMMIT has succeeded none of the changed data of the transactions is visible in other DMBS sessions.