On 6/7/22 12:28 PM, frame wrote:

My very common use of scope(failure) for my DB code:

conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");

This is hard to encapsulate into a type, as dtors only hook scope(exit) essentially.

-Steve

On Tuesday, 7 June 2022 at 18:37:13 UTC, Steven Schveighoffer wrote:

conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");

That's fine as the Throwable is still thrown but since scope(failure) acts as like catch-block, people may use it as replacement if there is something more to do.

I personally like the clean, short syntax when I don't care about the actual exception or if I know the called function has already handled the exception and just rethrows it:

bool fun() {
     scope(failure) {
         // do something
         return false;
     }

     badCode();
     return true;
}

I know this is bad as I'm capturing a possible error here - but this is what an unexperienced coder would do, because it works. The better approach would be to use scope(exception) (not typed, just as keyword) that allows to act only on Exceptions so one cannot break Exception vs Error paradigma and this also clarifies that usage of scope(failure) is potentially dangerous if you return from it.

Anyway, I just put that here - maybe you mention it in your blog.

On 6/7/22 3:58 PM, frame wrote:

conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");

bool fun() {
      scope(failure) {
          // do something
          return false;
      }

      badCode();
      return true;
}

Wait, what?

I'm looking at the spec and it says:

A scope(exit) or scope(success) statement may not exit with a throw, goto, break, continue, or return; nor may it be entered with a goto.

Which specifically does not include scope(failure).

I would never have expected that to be a "feature"...

Ali's linked bug report suggests that it's happening for Errors too, which is going to cause major problems if something didn't get cleaned up properly.

I will update the blog post. My recommendation is going to be, don't circumvent the propagation of the throwable for now. Instead use a try + catch(Exception). I think we need a compiler change to not allow return if it's catching an Error.

There may be other "weird" cases that are not covered by the spec. Is it legal to goto a label inside scope(failure)?

Thanks for the heads up!

-Steve

On Tuesday, 7 June 2022 at 18:37:13 UTC, Steven Schveighoffer wrote:
[...]

conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");

Are there multiple (successful) returns in your code or why are you executing the COMMIT under a scope exit clause? If there is only one successful return wouldn't it enhance code readability when an explicit COMMIT precedes the return?

Is the ROLLBACK really necessary? Isn't the transaction not committed (i.e. rolled back) when the db handle is closed? Why not have a Transaction class (struct)?

On Sunday, 5 June 2022 at 23:57:19 UTC, Steven Schveighoffer wrote:

Who is the narrator here? It is the author of the function which contains the assert. But this is not necessarily the author of the code which calls this function. Why should the author of the function be allowed to terminate the whole the program (be it via assert or exit)?

Because phobos/runtime throw Errors?

for(auto r = range; !r.empty; r.popFront) {
    auto elem = r.front;
}

for(auto r = range; !r.empty; r.popFront_unchecked) {
    auto elem = r.front_unchecked;
}

What shall go wrong in this example? Of course the compiler might generate wrong code. But it is not the aim of putting enforce and asserts into program code to guard against the bugs in the compiler.

On 6/12/22 4:11 PM, kdevel wrote:

conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");

No, usually just one (the implicit final return).

It just introduces another place where I can mess up the transaction. I can write these 3 lines, and be done, never having to worry about the transaction code again.

This is one of the major features of scope guards.

Yes. If you don't execute the rollback and start executing more DB calls, they all get included in the transaction (and might be expected to be).

Possibly, but I don't close the handle. It goes back to a pool to get reused.

A transaction class/struct cannot hook normal return and throwing differently (the destructor has no way of knowing whether an exception is in flight).

-Steve

On 6/13/22 9:15 AM, Steven Schveighoffer wrote:

Should have said "might not be expected to be"

-Steve

On Monday, 13 June 2022 at 13:15:42 UTC, Steven Schveighoffer wrote:

Um. I need a (fresh) connection per CGI process. I wonder if nowadays the TLS startup between the browser and the webserver isn't at least one or two magnitudes more expensive than the (unencrypted) connection to the domain socket of the DB engine. May pooling DB connections instead of closing them be optimizing on the wrong end?

Regarding C++: “[...] In a proper robust design, commits should always be explicit and destructors only rollback uncommitted transactions. [...]

There is now enough introspection in the language to actually implement implicit commit in a non exceptional path, but I think it would be a mistake."

[1] https://news.ycombinator.com/item?id=24648406

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.

I explained why, but you don't agree with the explanation. That's OK, we don't all have to write the same exact systems. D is a language that can satisfy many needs and philosophies! If you find it doesn't do it quite the way you want, and C++ does, C++ is also a fine language to use.

-Steve