Comparing Exceptions and Errors

[Steven Schveighoffer]

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