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
