Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

[Sergey Kovalev <kovserg33@...>]

I wonder why method is named __toclose but not __noreference ?

сб, 22 июн. 2019 г. в 17:19, Francisco Olarte <folarte@peoplecall.com>:
>
> David:
>
> On Sat, Jun 22, 2019 at 11:20 AM David Heiko Kolf <david@dkolf.de> wrote:
> > Francisco Olarte wrote:
> > > I'm nearly sure you are mixing concepts here, comparing try/finally
> ...
> > Unfortunately I haven't worked with Java for a long time but in C#
> > "using" and "finally" are actually equal and not different animals:
> > <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/using-statement>:
> > > You can achieve the same result by putting the object inside a try
> > > block and then calling Dispose in a finally block; in fact, this is
> > > how the using statement is translated by the compiler.
>
> Well, the same thing can be said of Java, and of many other languages
> which have with/using and try+finally. Using is just a shortcut which
> writes some code for you, but the same can be said of many constructs.
> What I was trying to bring forward is that when you make a program you
> use with/using for objects which have a purposefully built method,
> which does not throw errors, and which is / has benn tested
> separatelly. You use finally when your clean up block is more
> convoluted and needs logic depending on local state or similar things.
>
> > So far I have only used finally (in any language) for cleaning up
> > resources, too.
>
> But you do not use to clean up resources which are prepared to clean
> up themselves and tested, except when you are in one of does languages
> which force you to do it ( like java pre 7 ). Normally, when you write
> a library class, say a socket class, you add some closing method which
> can return errors, or throw, and may need the object alive to be
> processed. Then you add a method which does some "standard" error
> handling on the low-level one but wwhich does not throw and can be
> called without worrying about the result. I.e., closing a writable
> file can, and does, fail with ENOSPC. Closing a socket may fail if the
> other side is down. Some clients may need the details, but normally
> you just close it and forget. And, if your language supports
> with/using constructs, you normally enable the class to be used with
> them. But you do not normally use the low level, exception throwing,
> variant there, as it leads to difficult to read code. If you need this
> you use try/finally and call the more detailed close and handle the
> errors explicitly there. There are exceptions, but normally languages
> which allow faults in the closing tend to supress it and ignore the
> error, as a well written close method normally just throws in extreme
> cases.
>
> > Maybe my first example and some of my words weren't precise enough, but
> > anyway, what I meant is I want to be informed in case a cleanup method
> > for a resource didn't finish its job.
>
> That is part of whatI want to establish. A properly written cleanup
> method, designed for cleanup, should always finish the job. If your
> resource cannot be properly finalized, you should not use an
> automatically-called cleanup method, but write a finally block where
> the handling is explicit. I've found trying to do it the other way
> leads to lot of pain. Not all resources lend themselves to automatic
> cleanup.
>
> Francisco Olarte.
>