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

111–120 of 152 posts

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

#111

Post by brewmarche »

mort96 wrote: post #81
brewmarche wrote: post #49

Earlier quoted context omitted.

In C# the closest analogue to a C++ destructor would probably be a `using` block. You’d have to remember to write `using` in front of it, but there are static analysers for this. It gets translated to a `try`–`finally` block under the hood, which calls `Dispose` in `finally`. using (var foo = new Foo()) { } // foo.Dispose() gets called here, even if there is an exception Or, to avoid nesting: using var foo = new Foo(…

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?

You can move the burden of disposing to the caller (return the disposable object and let the caller put it in a using statement).

In addition, if the caller itself is a long-lived object it can remember the object and implement dispose itself by delegating. Then the user of the long-lived object can manage it.

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

#112

Post by mort96 »

brewmarche wrote: post #111
mort96 wrote: 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?

You can move the burden of disposing to the caller (return the disposable object and let the caller put it in a using statement). In addition, if the caller itself is a long-lived object it can remember the object and implement dispose itself by delegating. Then the user of the long-lived object can manage it.

> You can move the burden of disposing to the caller (return the disposable object and let the caller put it in a using statement).

That doesn't help. Not if the function that wants to return the disposable object in the happy path also wants to destroy the disposable object in the error path.

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

#113

Post by brewmarche »

mort96 wrote: post #112
brewmarche wrote: post #111

Earlier quoted context omitted.

You can move the burden of disposing to the caller (return the disposable object and let the caller put it in a using statement). In addition, if the caller itself is a long-lived object it can remember the object and implement dispose itself by delegating. Then the user of the long-lived object can manage it.

> You can move the burden of disposing to the caller (return the disposable object and let the caller put it in a using statement). That doesn't help. Not if the function that wants to return the disposable object in the happy path also wants to destroy the disposable object in the error path.

You have to write a disposable wrapper to return. Return it in error case too.

    readonly record struct Result(TResult? IfHappy, TDisposable? Disposable): IDisposable where TDisposable : IDisposable
    {
        public void Dispose() => Disposable?.Dispose();
    }

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

#114

Post by brewmarche »

brewmarche wrote: post #113
mort96 wrote: post #112

Earlier quoted context omitted.

> You can move the burden of disposing to the caller (return the disposable object and let the caller put it in a using statement). That doesn't help. Not if the function that wants to return the disposable object in the happy path also wants to destroy the disposable object in the error path.

You have to write a disposable wrapper to return. Return it in error case too. readonly record struct Result (TResult? IfHappy, TDisposable? Disposable): IDisposable where TDisposable : IDisposable { public void Dispose() => Disposable?.Dispose(); }

Usage at call site:

    using (var result = foo.GetSomethingIfLucky())
    {
        if (result.IfHappy is {} success)
        {
            // do something
        }
    }

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

#115

Post by otterley »

mort96 wrote: post #85
coliveira wrote: post #79

Earlier quoted context omitted.

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

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

It didn’t make sense to me, either, and I’m a native English speaker. The cultural reference was lost on me.

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

#116

Post by hyghjiyhu »

ibobev wrote: post #106
thombles wrote: post #5

Earlier quoted context omitted.

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.

It's important even without the meme. c++ has try-catch but not try-finally.

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

#117

Post by afiori »

otterley wrote: post #115
mort96 wrote: post #85

Earlier quoted context omitted.

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

It didn’t make sense to me, either, and I’m a native English speaker. The cultural reference was lost on me.

The requirement to avoid any cultural reference is a bit strict

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

#118

Post by afiori »

locknitpicker wrote: post #39
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…

> 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. Complaini…

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

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

#119

Post by afiori »

locknitpicker wrote: post #109
mandarax8 wrote: post #52

Earlier quoted context omitted.

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.

So inside a destructor throw has a radically different behaviour that makes it useless for communicating non-fatal errors

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

#120

Post by locknitpicker »

afiori wrote: post #119
locknitpicker wrote: post #109

Earlier quoted context omitted.

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

So inside a destructor throw has a radically different behaviour that makes it useless for communicating non-fatal errors

> So inside a destructor throw has a radically different behaviour that makes it useless for communicating non-fatal errors

It's weird how you tried to frame a core design feature of the most successful programming language in the history of mankind as "useless".

Perhaps the explanation lies in how you tried to claim that exceptions had any place in "communicating non-fatal errors", not to mention that your scenario, handling non-fatal errors when destroying a resource, is fundamentally meaningless.

Perhaps you should take a step back and think whether it makes sense to extrapolate your mental models to languages you're not familiar with.

Post reply on HN