Live data from Hacker News

C++ says “We have try... finally at home”

devblogs.microsoft.com

91–100 of 152 posts

Re: C++ says “We have try... finally at home”

#91
post #81

Earlier quoted context omitted.

That approach doesn't allow you to move the file into some long lived object or return it in the happy path though, does it?

As someone coming from RAII to C#, you get used to it, I'd say. You "just" have to think differently. Lean into records and immutable objects whenever you can and IDisposable interface ("using") when you can't. It's not perfect but neither is RAII. I'm on a learning path but I'd say I'm more productive in C# than I ever was in C++.

I agree with this. I don't dislike non-RAII languages (even though I do prefer RAII). I was mostly asking a rhetorical question to point out that it really isn't the same at all. As you say, it's not a RAII language, and you have to think differently than when using a RAII language with proper destructors.

Re: C++ says “We have try... finally at home”

#93

Destructors are vastly superior to the finally keyword because they only require us to remember a single time to release resources (in the destructor) as opposed to every finally clause. For example, a file always closes itself when it goes out of scope instead of having to be explicitly closed by the person who opened the file. Syntax is also less cluttered with less indentation, especially when multiple objects are…

Python has that too, it's called a context manager, basically the same thing as C++ RAII. You can argue that RAII is more elegant, because it doesn't add one mandatory indentation level.

How do you return a file in the happy path when using a context manager?

If you can't, it's not remotely "basically the same as C++ RAII".

Re: C++ says “We have try... finally at home”

#94

Destructors are vastly superior to the finally keyword because they only require us to remember a single time to release resources (in the destructor) as opposed to every finally clause. For example, a file always closes itself when it goes out of scope instead of having to be explicitly closed by the person who opened the file. Syntax is also less cluttered with less indentation, especially when multiple objects are…

The entire point of the article is that you cannot throw from a destructor. Now how do you signal that closing/writing the file in the destructor failed?

Just panic. What's the caller realistically going to do with that information?

Re: C++ says “We have try... finally at home”

#95
post #83

Earlier quoted context omitted.

Oh, come on man! These are trivial bugs . Whoever noticed it first should have sent the email to the mods. I did it before i posted my previous comment and i now see that the title has been changed appropriately.

7. hours.

Presumably nobody informed the mods (before i did) and it was very early in the morning in the US (assuming mods are based in the US). That would explain the delay.

Anyway, going forward, if anything like this happens again folks should simply shoot an email immediately to the mods and if the topic is really interesting deserving of more discussion they can always request the mods to keep the post on the frontpage for a longer time period via second-chance pool etc.

It just takes a minute or two of one's time and hence not worth getting het up over.

Re: C++ says “We have try... finally at home”

#96
post #82

Earlier quoted context omitted.

What do you do if you wanna return the file (or an object containing the file) in the happy path but close it in the error path?

You'd write it like this void bar() { try (var f = foo()) { doMoreHappyPath(f); } catch(IOException ex) { handleErrors(); } } File foo() throws IOException { File f = openFile(); doHappyPath(f); if (badThing) { throw new IOException("Bad thing"); } return f; } That said, I think this is a bad practice (IMO). Generally speaking I think the opening and closing of a resource should happen at the same scope. Making it no…

In Java, I agree with you that the opening and closing of a resource should happen at the same scope. This is a reasonable rule in Java, and not following it in Java is a recipe for errors because Java isn't RAII.

In C++ and Rust, that rule doesn't make sense. You can't make the mistake of forgetting to close the file.

That's why I say that Java, Python and C#'s context managers aren't remotely the same. They're useful tools for resource management in their respective languages, just like defer is a useful tool for resource management in Go. They aren't "basically RAII".

Re: C++ says “We have try... finally at home”

#97

Destructors are vastly superior to the finally keyword because they only require us to remember a single time to release resources (in the destructor) as opposed to every finally clause. For example, a file always closes itself when it goes out of scope instead of having to be explicitly closed by the person who opened the file. Syntax is also less cluttered with less indentation, especially when multiple objects are…

The entire point of the article is that you cannot throw from a destructor. Now how do you signal that closing/writing the file in the destructor failed?

You are allowed to throw from a destructor as long as there's not already an active exception unwinding the stack. In my experience this is a total non-issue for any real-world scenario. Propagating errors from the happy path matters more than situations where you're already dealing with a live exception.

For example: you can't write to a file because of an I/O error, and when throwing that exception you find that you can't close the file either. What are you going to do about that other than possibly log the issue in the destructor? Wait and try again until it can be closed?

If you really must force Java semantics into it with chains of exception causes (as if anybody handled those gracefully, ever) then you can. Get the current exception and store a reference to the new one inside the first one. But I would much rather use exceptions as little as possible.

Re: C++ says “We have try... finally at home”

#98
post #83

Earlier quoted context omitted.

7. hours.

Presumably nobody informed the mods (before i did) and it was very early in the morning in the US (assuming mods are based in the US). That would explain the delay. Anyway, going forward, if anything like this happens again folks should simply shoot an email immediately to the mods and if the topic is really interesting deserving of more discussion they can always request the mods to keep the post on the frontpage fo…

It would be easier for everyone involved, and not depend on mods being awake, if HN didn't just automatically drastically change the meaning of headlines.

Again, this post was misrepresenting Raymond's words for over 7 hours. That's most of its time on the front page. The current system doesn't work.

Re: C++ says “We have try... finally at home”

#99
post #90

In other words: Footgun #17421 Exhibit A.

What the blog doesn't mention is how try finally can mess up your control flow. In Java the following is perfectly valid: try { throw new IllegalStateException("Critical error"); } finally { return "Move along, nothing to see here"; }

Yes, Java has footguns too.

The existence of two different patterns each with their own pitfalls is why we can’t have nice things. Finally shouldn’t return a value. Simply a void expression. Exception driven API’s need to be snuffed out.

If your method throws, mark it as such as force me to handle the exception if it does, do not return a non-value value in a finally.

Using Java as the example shows just how far we have come with this thinking, why old school Java style exception handling sucks and why C++ by proxy does too.

It’s difficult to break old mental habits but it’s easier when the compiler yells at you for doing bad things.

Re: C++ says “We have try... finally at home”

#100
post #11

Earlier quoted context omitted.

It does... until you switch employers. Or sometimes even just read a coworker's code. Or even your own older code. Actually no, I don't think anyone achieved full readability enlightenment. People like me just hallucinated it after doing the same things for too long.

And yet, somehow Lisp continues to be everyone's sweetheart, even though creating literal new DSLs for every project is one of the features of the language.

I continue to believe Lisp is perfect, despite only using it in a CS class a decade ago. Come to think of it, it might just be that Lisp is a perfect DSL for (among other things) CS classes…
Post reply on HN