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

https://devblogs.microsoft.com/oldnewthing/20251222-00/?p=111890

by ibobev • 7 months ago

149 143 7 months ago

devblogs.microsoft.com

jasode• 7 months ago

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 <X>? No, we have <X> 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++ refrigerator and it's called 'destructor'"

To continue the meme analogy, the kid's idea of <X> doesn't match mom's idea of <X> and disagrees that they're equivalent. E.g. "Mom, can we order pizza? No, we have leftover casserole in the fridge."

So some kids would complain that C++ destructors RAII philosophy require creating a whole "class X{public:~X()}" which is sometimes inconvenient so it doesn't exactly equal "finally".

thombles• 7 months ago

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

tux3• 7 months ago

It's rare to see the mangling heuristics improve a title these days. There was a specific type of clickbait title that was overused at the time, so a rule was created. And now that the original problem has passed, we're stuck with it.

mort9616• 7 months ago

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 somewhat exaggerated original post title.

As it stands, the HN title suggests that Raymond thinks the C++ 'try' keyword is a poor imitation of some other language's 'try'. In reality, the post is about a way to mimic Java's 'finally' in C++, which the original title clearly (if humorously) encapsulates. Raymond's words have been misrepresented here for over 4 hours at this point. I do not understand how this is an acceptable trade-off.

pjmlp• 7 months ago

You have a few minutes to change the title after the submission, I do it all the time.

ibobev2• 7 months ago

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.

vidarh• 7 months ago

I'm curious about the actual origin now, given that a quick search shows only vague references or claim it is recent, but this meme is present in Eddie Murphys "Raw" from 1987, so it is at least that old.

pelorat3• 7 months ago

Sounds like a perfect fit for some Deep Research.

Edit: A deep research run by Gemini 3.0 Pro says the origin is likely to be stand-up comedy routines between 1983–1987 and particularly mentions Eddie Murphy, and the 1983 socioeconomic precursor "You ain't got no McDonald's money" in Delirious (1983) culminating in the meme from in Raw (1987). So Eddie might very well be the original origin.

locknitpicker4• 7 months ago

So some kids would complain that C++ destructors RAII philosophy require creating a whole "class X{public:~X()}" which is sometimes inconvenient so it doesn't exactly equal "finally".

Those figurative kids would be stuck in a mental model where they try to shoehorn their ${LanguageA} idioms onto applications written in ${LanguageB}. As the article says, C++ has destructors since the "C with Classes" days. Complaining that you might need to write a class is specious reasoning because if you have a resource worth managing, you already use RAII to manage it. And RAII is one of the most fundamental and defining features of C++.

It all boils down to whether one knows what they are doing, or even bothers to know what they are doing.

afiori3• 7 months ago

Ok, but sometimes you just need a single line in a finally and writing a class is more annoying

coliveira• 7 months ago

That's why you shouldn't use memes in the titles of technical articles. The intelligibility of your intent is vastly reduced.

mort9616• 7 months ago

The title of the blog post is perfectly intelligible. It becomes unintelligible when you remove random words from it.

mojuba4• 7 months ago

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`.

dwattttt• 7 months ago

I was contemplating what it would look like to provide this with a macro in Rust, and of course someone has already done it. It's syntactic sugar for the destructor/RAII approach.

https://docs.rs/defer-rs/latest/defer_rs/

mojuba4• 7 months ago

I don't know Rust but, can this `defer` evaluate after the `return` statement is evaluated like in Swift? Because in Swift you can do this:

    func atomic_get_and_inc() -> Int {
        sem.wait()
        defer {
            value += 1
            sem.signal()
        }
        return value
    }

troglo-byte2• 7 months ago

    #include <iostream>
    #define RemParens_(VA) RemParens__(VA)
    #define RemParens__(VA) RemParens___ VA
    #define RemParens___(...) __VA_ARGS__
    #define DoConcat_(A,B) DoConcat__(A,B)
    #define DoConcat__(A,B) A##B
    #define defer(BODY) struct DoConcat_(Defer,__LINE__) { ~DoConcat_(Defer,__LINE__)() { RemParens_(BODY) } } DoConcat_(_deferrer,__LINE__)

    int main() {
        {
            defer(( std::cout << "Hello World" << std::endl; ));
            std::cout << "This goes first" << std::endl;
        }
    }

rezonant• 7 months ago

Why would that be preferable to just using an RAII style scope_exit with a lambda

chuckadams• 7 months ago

"We have syntax macros at home"

pelorat3• 7 months ago

And here I thought we were trying to finally kill off pre-processor macros.

Someone2• 7 months ago

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 verify that you didn’t forget the revert_foo part than when there are many lines between foo and the finally block that calls revert_foo.

A disadvantage is that defer breaks the “statements are logically executed in source code order” convention. I think that’s more than worth it, though.

mojuba4• 7 months ago

Yeah, it's especially handy in UI code where you can have asynchronous operations but want to have a clear start/end indication in the UI:

    busy = true
    Task {
        defer { busy = false }
        // do async stuff, possibly throwing exceptions and whatnot
    }

kibwen4• 7 months ago

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.

Snarwin• 7 months ago

The oldest defer-like feature I can find reference to is the ON_BLOCK_EXIT macro from this article in the December 2000 issue of the C/C++ Users Journal:

https://jacobfilipp.com/DrDobbs/articles/CUJ/2000/cexp1812/a...

A similar macro later (2006) made its way into Boost as BOOST_SCOPE_EXIT:

https://www.boost.org/doc/libs/latest/libs/scope_exit/doc/ht...

I can't say for sure whether Go's creators took inspiration from these, but it wouldn't be surprising if they did.

tryfinally• 7 months ago

I always wonder whether C++ syntax ever becomes readable when you sink more time into it, and if so - how much brain rewiring we would observe on a functional MRI.

sigmoid10• 7 months ago

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.

usrnm2• 7 months ago

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.

Yoric• 7 months ago

Sadly, that is exactly my experience.

m-schuetz2• 7 months ago

"using namespace std;" goes a long way to make C++ more readable and I don't really care about the potential issues. But yeah, due to a lack of a nice module system, this will quickly cause problems with headers that unload everything into the global namespace, like the windows API.

I wish we had something like Javascript's "import {vector, string, unordered_map} from std;". One separate using statement per item is a bit cumbersome.

delta_p_delta_x• 7 months ago

Standard library modules: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p24...

I have thoroughly forgotten which header std::ranges::iota comes from. I don't care either.

deliciousturkey• 7 months ago

In my opinion, C++ syntax is pretty readable. Of course there are codebases that are difficult to read (heavily abstracted, templated codebases especially), but it's not really that different compared to most other languages. But this exists in most languages, even C can be as bad with use of macros.

By far the worst in this aspect has been Scala, where every codebase seems to use a completely different dialect of the language, completely different constructs etc. There seems to have very little agreement on how the language should be used. Much, much less than C++.

speed_spread• 7 months ago

Scala is a meta language. It's really a language construction toolkit in a box.

rramadass9• 7 months ago

This is just a low-effort comment.

whether C++ syntax ever becomes readable when you sink more time into it,

Yes, and the easy approach is to learn as you need/go.

pelorat3• 7 months ago

It's very readable, especially compared to Rust.

Mond_• 7 months ago

I love how the haters of Rust's syntax can be roughly divided into two groups:

(1) Why doesn't it look like C++?

(2) Why does it look so much like C++?

abbefaria27• 7 months ago

It does get easy to read, but then you unlock a deeper level of misery which is trying to work out the semantics. Stuff like implicit type conversions, remembering the rule of 3 or 5 to avoid your std::moves secretly becoming a copy, unwittingly breaking code because you added a template specialization that matches more than you realized, and a million others.

verall• 7 months ago

This is correct - it does get easy to read but you are constantly considering the above semantics, often needing to check reference or compiler explorer to confirm.

Unless you are many of my coworkers, then you blissfully never think about those things, and have Cursor reply for you when asked about them (-:

winternewt2• 7 months ago

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 created that require nested try... finally blocks. Not to mention how branching and conditional initialization complicates things. You can often pair up constructors with destructors in the code so that it becomes very obvious when resource acquisition and release do not match up.

jchw5• 7 months ago

Destructors and finally clauses serve different purposes IMO. Most of the languages that have finally clauses also have destructors.

Syntax is also less cluttered with less indentation, especially when multiple objects are created that require nested try... finally blocks.

I think that's more of a point against try...catch/maybe exceptions as a whole, rather than the finally block. (Though I do agree with that. I dislike that aspect of exceptions, and generally prefer something closer to std::expected or Rust Result.)

mort9616• 7 months ago

Most of the languages that have finally clauses also have destructors.

Hm, is that true? I know of finally from Java, JavaScript, C# and Python, and none of them have proper destructors. I mean some of them have object finalizers which can be used to clean up resources whenever the garbage collector comes around to collect the object, but those are not remotely similar to destructors which typically run deterministically at the end of a scope. Python's 'with' syntax comes to mind, but that's very different from C++ and Rust style destructors since you have to explicitly ask the language to clean up resources with special syntax.

Which languages am I missing which have both try..finally and destructors?

sigwinch28• 7 months ago

A writable file closing itself when it goes out of scope is usually not great, since errors can occur when closing the file, especially when using networked file systems.

https://github.com/isocpp/CppCoreGuidelines/issues/2203

leni536• 7 months ago

Any fallible cleanup function is awkward, regardless of error handling mechanism.

mort9616• 7 months ago

You need to close it and check for errors as part of the happy path. But it's great that in the error path (be that using an early return or throwing an exception), you can just forget about the file and you will never leak a file descriptor.

You may need to unlink the file in the error path, but that's best handled in the destructor of a class which encapsulates the whole "write to a temp file, rename into place, unlink on error" flow.

dist-epoch2• 7 months ago

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.

logicchains• 7 months ago

It's not the same thing at all because you have to remember to use the context manager, while in C++ the user doesn't need to write any extra code to use the destructor, it just happens automatically.

mort9616• 7 months ago

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".

yoshuaw• 7 months ago

I couldn't agree more. And in the rare cases where destructors do need to be created inline, it's not hard to combine destructors with closures into library types.

To point at one example: we recently added `std::mem::DropGuard` [1] to Rust nightly. This makes it easy to quickly create (and dismiss) destructors inline, without the need for any extra keywords or language support.

[1] https://doc.rust-lang.org/nightly/std/mem/struct.DropGuard.h...

raverbashing• 7 months ago

But they're addressing different problems

Sure destructors are great but you still want a "finally" for stuff you can't do in a destructor

mandarax8• 7 months ago

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?

DonHopkins• 7 months ago

That tastes like leftover casserole instead of pizza.

EPWN3D• 7 months ago

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

winternewt2• 7 months ago

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.

locknitpicker4• 7 months ago

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.

WalterBright2• 7 months ago

The scope guard statement is even better!

https://dlang.org/articles/exception-safe.html

https://dlang.org/spec/statement.html#ScopeGuardStatement

Yes, D also has destructors.

Defletter• 7 months ago

Scope guards are neat, particularly since D has had them since 2006! (https://forum.dlang.org/thread/dtr2fg$2vqr$4@digitaldaemon.c...) But they are syntactically confusing since they look like a function invocations with some kind of aliased magic-value passed in.

indiosmo• 7 months ago

I use this library a lot for scope guards in C++ https://github.com/Neargye/scope_guard, especially for rolling back state on errors, e.g.

In a function that inserts into 4 separate maps, and might fail between each insert, I'll add a scope exit after each insert with the corresponding erase.

Before returning on success, I'll dismiss all the scopes.

I suppose the tradeoff vs RAII in the mutex example is that with the guard you still need to actually call it every time you lock a mutex, so you can still forget it and end up with the unreleased mutex, whereas with RAII that is not possible.

NooneAtAll3• 7 months ago

Update: Adam Rosenfield points out that Python 3.2 now saves...

how old is this post that 3.2 is "now"?

tln• 7 months ago

I think the author didn't check the age of Python 3.2 when adding the update

reactordev2• 7 months ago

In other words: Footgun #17421 Exhibit A.

josefx• 7 months ago

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"; }

reactordev2• 7 months ago

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.

Maxatar• 7 months ago

Why is this a footgun? This seems no different than using a try/catch.

try { throw new IllegalStateException("Critical error"); } catch(Exception) { return "Move along, nothing to see here"; }

firesteelrain• 7 months ago

This is a good “how C++ does it” explanation, but I think it’s more accurate to say destructors implement finally-style cleanup in C++, not that they are finally. finally is about operation-scoped cleanup; destructors are about ownership. C++ just happens to use the same tool for both.

meindnoch2• 7 months ago

Calling arbitrary callbacks from a destructor is a bad idea. Sooner or later someone will violate the requirement about exceptions, and your program will be terminated immediately. So I'd only use this pattern in -fno-exceptions projects.

In a similar vein, care must be taken when calling arbitrary callbacks while iterating a data structure - because the callback may well change the data structure being iterated (classic example is a one-shot event handler that unsubscribes when called), which will break naïvely written code.

fjjdrnrbbrb• 7 months ago

Throwing exceptions in destructors in C++ is fine, as long as your code is exception safe.

What exactly are you referring to?

meindnoch2• 7 months ago

Throwing exceptions from destructors is "fine", except when the destructor is executed by stack unwinding (triggered by an earlier exception), in which case throwing will terminate the program with std::terminate.

kentonv• 7 months ago

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 of the original exception. Reporting the finally exception obscures information about the root cause, making it harder to debug the problem.

Many of these languages do attach the original exception to the new exception in some way, so you can get at it if you need to, but whatever actually catches and logs the exception later has to go out of its way to make sure to log the root cause rather than some stupid side effect. The hierarchy should be reversed: the exception thrown by `finally` should be added as an attachment to the original exception, perhaps placed in a list of "secondary" errors. Or you could even just throw it away, honestly the original exception is almost always all you care about anyway.

(C++ of course did much worse by just crashing in this scenario. I imagine this to be the outcome of some debate in the committee where they couldn't decide which exception should take priority. And now everyone has internalized this terrible decision by saying "well, destructors shouldn't throw" without seeming to understand that this is equivalent to saying "destructors shouldn't have bugs". WELL OF COURSE THEY SHOULDN'T BUT GOOD LUCK WITH THAT.)

uncivilized2• 7 months ago

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.

fooofw• 7 months ago

I believe this might be slightly imprecise also.

The traceback is actually shown based on the last-thrown exception (that thrown from the finally in this example), but includes the previous "chained exceptions" and prints them first. From CPython docs [1]:

When raising a new exception while another exception is already being handled, the new exception’s __context__ attribute is automatically set to the handled exception. An exception may be handled when an except or finally clause, or a with statement, is used. [...] The default traceback display code shows these chained exceptions in addition to the traceback for the exception itself. [...] In either case, the exception itself is always shown after any chained exceptions so that the final line of the traceback always shows the last exception that was raised.

So, in practice, you will see both tracebacks. However, if you, say, just catch the exception with a generic "except Exception" or whatever and log it without "__context__", you will miss the firstly thrown exception.

[1] https://docs.python.org/3.14/library/exceptions.html#excepti...

greesil• 7 months ago

Who needs finally when we have goto?

Rochus• 7 months ago

e.g. people who use exceptions and don't use destructors?

zvvnkjvxd• 7 months ago

I'm quite sure that an exception thrown in finally block in java will have the original as suppressed, not discarded

cjj_swe• 7 months ago

I was hoping absl::Cleanup would get a shoutout. I worked hard to make it ergonomic and performant. For those looking for something (imo) better than the standard types, check it out!

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

Related Stories