June 15

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

>

I don't see what you see wrong with the code I wrote. It's straightforward, obvious, and does the job I need it to do, in a way that's not prone to future mistakes.

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

June 15

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

>

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

>

I don't see what you see wrong with the code I wrote. It's straightforward, obvious, and does the job I need it to do, in a way that's not prone to future mistakes.

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

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

June 16

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

>

[...]
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?

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.

June 16

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

>

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

>

[...]
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?

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.

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

June 16

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

> >

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

Quote (again): "A [...] scope(success) statement may not exit with a throw [...]."
[...]
If the spec forbids it, but the compiler allows it, wouldn't it then be a bug?

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

June 16

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

>

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

> >

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

Quote (again): "A [...] scope(success) statement may not exit with a throw [...]."
[...]
If the spec forbids it, but the compiler allows it, wouldn't it then be a bug?

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

Throwing in a scope guard.

June 16

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

>

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

>

[...]
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?

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 [...]."

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.

>

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.

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

-Steve

June 16

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

[scope (success) lowered to finally]

[...]

> >

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.

Semantically, you are just not undoing (rollback) the previous steps.

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.

1 2 3 4 5 6 7 8
Next ›   Last »