Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devblogs.microsoft.com

Post reply on HN
Print view View original

101–110 of 152 posts

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

#101

Post by miki123211 »

mort96 wrote: post #9
thombles wrote: post #5

Earlier quoted context omitted.

HN has some heuristics to reduce hyperbole in submissions which occasionally backfire amusingly.

Yeah it's a huge mistake IMO. I see it fucking up titles so frequently, and it flies in the face of the "do not editorialise titles" rule: [...] please use the original title, unless it is misleading or linkbait; don't editorialize. It is much worse, I think, to regularly drastically change the meaning of a title automatically until a moderator happens to notice to change it back, than to allow the occasional somewha…

Submissions with titles that undergo this treatment should get a separate screen where both titles are proposed, and the ultimate choice belongs to the submitter.

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

#102

Post by mort96 »

miki123211 wrote: post #101
mort96 wrote: post #9

Earlier quoted context omitted.

Yeah it's a huge mistake IMO. I see it fucking up titles so frequently, and it flies in the face of the "do not editorialise titles" rule: [...] please use the original title, unless it is misleading or linkbait; don't editorialize. It is much worse, I think, to regularly drastically change the meaning of a title automatically until a moderator happens to notice to change it back, than to allow the occasional somewha…

Submissions with titles that undergo this treatment should get a separate screen where both titles are proposed, and the ultimate choice belongs to the submitter.

That would be an excellent solution I think.

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

#103

Post by cogman10 »

mort96 wrote: post #96
cogman10 wrote: post #86

Earlier quoted context omitted.

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 u…

> You can't make the mistake of forgetting to close the file.

But you can make a few mistakes that can be hard to see. For example, if you put a mutex in an object you can accidentally hold it open for longer than you expect since you've now bound the life of the mutex to the life of the object you attached it to. Or you can hold a connection to a DB or a file open for longer than you expected by merely leaking out the file handle and not promptly closing it when you are finished with it.

Trying to keep resource open and close in the same scope is an ownership thing. Even for C++ or Rust, I'd consider it not great to leak out RAII resources from out of the scope that acquired them. When you spread that sort of ownership throughout the code it becomes hard to conceptualize what the state of a program would be at any given location.

The exception is memory.

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

#104

Post by kibwen »

Someone wrote: post #48
mojuba wrote: post #3

I like how Swift solved this: there's a more universal `defer { ... }` block that's executed at the end of a given scope no matter what, and after the `return` statement is evaluated if it's a function scope. As such it has multiple uses, not just for `try ... finally`.

I think Swift’s defer ( https://docs.swift.org/swift-book/documentation/the-swift-pr... ) was inspired by/copied from go ( https://go.dev/tour/flowcontrol/12 ), but they may have taken it from an even earlier language that I’m not aware of. Defer has two advantages over try…finally: firstly, it doesn’t introduce a nesting level. Secondly, if you write foo defer revert_foo , when scanning the code, it’s easier to veri…

I'll disagree here. I'd much rather have a Python-style context manager, even if it introduces a level of indentation, rather than have the sort of munged-up control flow that `defer` introduces.

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

#105

Post by vkazanov »

lmz wrote: post #35
vkazanov wrote: post #20

Earlier quoted context omitted.

Lisp doesnt have much syntax to speak of. All of the DSLs use the same basic structure and are easy to read. Cpp has A LOT A of syntax: init rules, consts, references, move, copy, templates, special cases, etc. It also includes most of C, which is small but has so many basic language design mistakes that "C puzzles" is a book.

The syntax and the concepts (const, move, copy, etc) are orthogonal. You could possibly write a lisp / s-exp syntax for c++ and all it would make better would be the macros in the preprocessor. The DSL doesn't have to be hard to read if it uses unfamiliar/uncommon project specific concepts.

Yes, sure.

What i mean is that in cpp all the numerous language features are exposed through little syntax/grammar details. Whereas in Lisps syntax and grammar are primitive, and this is why macros work so well.

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

#106

Post by ibobev »

thombles wrote: post #5
jasode wrote: post #2

The submitted title is missing the salient keyword "finally" that motivates the blog post. The actual subtitle Raymond Chen wrote is: "C++ says “We have try…finally at home.”" It's a snowclone based on the meme, "Mom, can we get ? No, we have at home." : https://www.google.com/search?q=%22we+have+x+at+home%22+meme In other words, Raymond is saying... "We already have Java feature of 'finally' at home in the C++ refri…

HN has some heuristics to reduce hyperbole in submissions which occasionally backfire amusingly.

I intentionally shortened the title because there is a length limit. Perhaps I didn't do it the right way because I was unfamiliar with the mentioned meme. Sorry about that.

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

#107

Post by jchw »

rramadass wrote: post #47
jchw wrote: post #38

Earlier quoted context omitted.

I don't view finalizers and destructors as different concepts. The notion only matters if you actually need cleanup behavior to be deterministic rather than just eventual, or you are dealing with something like thread locals. (Historically, C# even simply called them destructors.)

> I don't view finalizers and destructors as different concepts. They are fundamentally different concepts. See Destructors, Finalizers, and Synchronization by Hans Boehm - https://dl.acm.org/doi/10.1145/604131.604153

It would suffice to say I don't always agree with even some of the best in the field, and they don't always agree with each other, either. Anders Hejlsberg isn't exactly a random n00b when it comes to programming language design and still called the C# equivalent a "destructor", though it is now known as a finalizer in line with other programming languages. They are things that clean up resources at the end of the life of an object; the difference between GC'd languages and RAII languages is that in a GC'd runtime the lifespan of an object is non-deterministic. That may very well change the programming model, as it does in many other ways, but it doesn't make the two concepts "fundamentally different" by any means. They're certainly related concepts...

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

#109

Post by locknitpicker »

mandarax8 wrote: post #52
winternewt wrote: post #21

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?

> The entire point of the article is that you cannot throw from a destructor.

You need to read the article again because your assertion is patently false. You can throw and handle exceptions in destructors. What you cannot do is not catch those exceptions, because as per the standard uncaught exceptions will lead the application to be immediately terminated.

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

#110

Post by uncivilized »

kentonv wrote: post #74

> In Java, Python, JavaScript, and C# an exception thrown from a finally block overwrites the original exception, and the original exception is lost. Pet peeve of mine: all these languages got it wrong. (And C++ got it extra-wrong.) The error you want to log or report to the user is almost certainly the original exception, not the one from the finally block. The error from the finally block is probably a side effect…

This part is not correct. I can't speak for the other languages, but in Python the exception that is originally thrown is the one that creates the traceback. If the finally block also throws an exception, then the traceback includes that as additional information. The author includes an addendum, yet he is still wrong about which exception is first raised.
Post reply on HN