Lua 5.4.0-alpha-rc1 behavior with closing methods errors

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Lua 5.4.0-alpha-rc1 behavior with closing methods errors

phlnc8
What happens when closing methods error?

To make the test short and simple, I added a closing method to
strings, with a silly error condition (closing errors when string
length is 3 -- see code below)

    --let's define a closing method on strings
    -- (just to make the test simpler/shorter)
    string_mt = getmetatable('a')
    function string_mt.__close(s)
        print("closing " .. s)
        if #s == 3 then
            print("before error " .. s)
            error("err closing ".. s) end
    end

    function test1()
    local <toclose> x='XXX'-- closing should error
    end

    function test2()
    --~ local <toclose> x='XXX'-- closing should error
    local <toclose> y='YY' -- closing is ok
    local <toclose> z='ZZZ' -- closing should error
    print("x, z are in scope: ", x, z, "let's raise an error")
    assert(false, "something is wrong!")
    print("Is this executed? No, the assert above has raised an error")
    end

    -- test1()

    test2() -- the _last raised_ error is reported. no traceback

with test1(), the program runs as expected. "Closing" 'x' errors. The
closing error is reported with a traceback.

with test2(), the _last_ closing error is reported (i.e. closing 'x').
There is no traceback. The first encoutered errors (the failed assert
withing the function body, and the error closing 'z') are raised, but
then not reported..

With this behavior, it looks like an error within the body of a block
is "masked" by any error in a closing method.

I think the expected behavior would be:

1. attempt to execute all the closing methods (as Lua-5.4.0 does now),
but report _the first encountered error_, instead of the last (in this
example, reporting the assert failure)

2. include by default a traceback for the reported error even if there
are more than one closing errors

Phil

Reply | Threaded
Open this post in threaded view
|

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

phlnc8
On Thu, Jun 6, 2019 at 5:23 PM phlnc8 <[hidden email]> wrote:
> What happens when closing methods error?
> ...

The first line of "test2()" in my previous message should not be commented out.
  function test2()
    local <toclose> x='XXX'-- closing should error
    ...

My bad.

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by phlnc8
> What happens when closing methods error?
>
> [...]
>
> I think the expected behavior would be:
>
> 1. attempt to execute all the closing methods (as Lua-5.4.0 does now),
> but report _the first encountered error_, instead of the last (in this
> example, reporting the assert failure)
>
> 2. include by default a traceback for the reported error even if there
> are more than one closing errors

The current behavior is to report the last error. This actually masks
the original error, which might be the cause for the other errors.
Besides, because these extra errors are run in a different environment
(because the first error exited the original one), they have no traceback.

We will change that to report the original error, which naturally
has the traceback.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

nobody

On 06/06/2019 20.44, Roberto Ierusalimschy wrote:

>> What happens when closing methods error?
>>
>> [...]
>>
>> I think the expected behavior would be:
>>
>> 1. attempt to execute all the closing methods (as Lua-5.4.0 does now),
>> but report _the first encountered error_, instead of the last (in this
>> example, reporting the assert failure)
>>
>> 2. include by default a traceback for the reported error even if there
>> are more than one closing errors
>
> The current behavior is to report the last error. This actually masks
> the original error, which might be the cause for the other errors.
> Besides, because these extra errors are run in a different environment
> (because the first error exited the original one), they have no traceback.
>
> We will change that to report the original error, which naturally
> has the traceback.

Haven't looked at this part of the new version in detail yet, but isn't
this a good place to use the new warning mechanism?

-- nobody

Reply | Threaded
Open this post in threaded view
|

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

phlnc8
In reply to this post by Roberto Ierusalimschy
On Thu, Jun 6, 2019 at 6:45 PM Roberto Ierusalimschy
<[hidden email]> wrote:
>
> We will change that to report the original error, which naturally
> has the traceback.

I see it done in -rc2. Thanks!

Phil

Reply | Threaded
Open this post in threaded view
|

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

David Heiko Kolf-2
In reply to this post by phlnc8
phlnc8 wrote:

> with test2(), the _last_ closing error is reported (i.e. closing 'x').
> There is no traceback. The first encoutered errors (the failed assert
> withing the function body, and the error closing 'z') are raised, but
> then not reported..
>
> With this behavior, it looks like an error within the body of a block
> is "masked" by any error in a closing method.
>
> I think the expected behavior would be:
>
> 1. attempt to execute all the closing methods (as Lua-5.4.0 does now),
> but report _the first encountered error_, instead of the last (in this
> example, reporting the assert failure)

In C# the last error is reported and I actually think that is the right
decision.
<https://stackoverflow.com/questions/2911215/what-happens-if-a-finally-block-throws-an-exception>

Consider this program with two errors, where at least one is a
programming mistake:

  do
    local z
    local <toclose> resource = setmetatable({}, {
      __close = function ()
        z.closed = true -- error 2, z might be nil
      end
    })

    error "something went wrong" -- error 1
    z = {}
  end

If the first error is reported I will never even know that there was a
second error. And once I fixed the first error, I probably won't see
that there is problem with my __close function.

However, if the last error is reported, I can fix that and after fixing
it I will still see the first error.

Best regards,

David

Reply | Threaded
Open this post in threaded view
|

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

nobody
On 20/06/2019 13.19, David Heiko Kolf wrote:
> In C# the last error is reported and I actually think that is the
> right decision.
>
> […]
>
> If the first error is reported I will never even know that there was
> a second error. And once I fixed the first error, I probably won't
> see that there is problem with my __close function.

The situation that caused the last error is potentially caused by an
arbitrarily large number of (mis-/un-)handled errors that happened
before that, and the data that your __close has to work with is
arbitrarily insane.  If you want to have a chance to work your way back
to the earlier errors, you'll have to write paranoid (long, unreadable)
code.

Only the first error in the chain is certainly caused by an actual
problem.  All later errors are potentially just interface/invariant
violations caused by the first error, and it's not your(/__close's) job
to navigate the mess caused by interface-/invariant-violating code.

If something's supposed to be a table but isn't, whoever didn't create
that table is to blame, not the __close that amplifies the (previously
silent) error.  (If the table (or subobject, …) creation might fail,
have an .is_valid flag?  Or better yet, don't mark it as <toclose>
before it actually makes sense to close it…)




How would you "fix" this "error" in your example?  I don't see anything
wrong there.

> __close = function( )  z.closed = true  end -- error, z might be nil

If anything, I might add a loud check that z is a table (or
__index-able), but Lua's error message ("attempt to index a nil value")
already says that (and even includes the type of the value, and
potentially its name!) – so a manual check would just add more code to
produce a less informative error message… so actually there is nothing
to fix?  (What am I missing? O.o)

-- nobody

Reply | Threaded
Open this post in threaded view
|

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

Francisco Olarte
In reply to this post by David Heiko Kolf-2
David:

On Thu, Jun 20, 2019 at 1:19 PM David Heiko Kolf <[hidden email]> wrote:
> > 1. attempt to execute all the closing methods (as Lua-5.4.0 does now),
> > but report _the first encountered error_, instead of the last (in this
> > example, reporting the assert failure)
>
> In C# the last error is reported and I actually think that is the right
> decision.
> <https://stackoverflow.com/questions/2911215/what-happens-if-a-finally-block-throws-an-exception>

Just my two cents. I'm not a C# programmer, but this sounds similar to
Java finallys. If you make a "library class", like a file or socket,
and you provide a full-parameter closing method to be called in
finally, there is no problem in throwing, as finally is a block which
can have it's own exception handling. But, if you implement closeable
to use your object in a "try-with-resources", which I think is the
closest match to <toclose>, your exceptions are swallowed ( IIRC they
are stashed somewhere, but swallowed anyway ).

C++, allowing RAII, dows not need finally, but has a similar
"destructors do not throw mantra". And if you decide to build and use
any of the "finally" constructs, like the ones in the GSL, you can
have exception handling in them.

In both cases you normally use a similar strategy if you need it. You
have a full closing method, which may throw, and a potentially dumber
and safer no-throwing ( no erroring in the lua case ) one to be used
in the "autoclosing" paths, try-with-resources, C++ dtors, and, IMO,
lua's toclose.

IMO __close methods belong to resource/service objects, and it's no
throw behaviour can normally be unit tested on them, giving a way to
easily catch errors in them will lead to more difficult code in the
well written cases and, what is worst, send a message theat "throwing
in __close" is ok, and instigate people to write __close without care.


> Consider this program with two errors, where at least one is a
> programming mistake:
>   do
>     local z
>     local <toclose> resource = setmetatable({}, {
>       __close = function ()
>         z.closed = true -- error 2, z might be nil
>       end
>     })
>     error "something went wrong" -- error 1
>     z = {}
>   end
> If the first error is reported I will never even know that there was a
> second error. And once I fixed the first error, I probably won't see
> that there is problem with my __close function.
> However, if the last error is reported, I can fix that and after fixing
> it I will still see the first error.

That's true, but IMO a construct like that ( oportunistic closeing
code written in the same code chunk as the mian one ) would be better
served by one of the many ways you can simulate a try/finally.

Taking Java as a example again, as I do not do C#. If I got one thing
like this I use a try/finally. If I have a class with a common
finalization code which has to run a lot I wrap it in a Closeable,
unit test it to get sure close() is right and then use
try-with-resources.

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

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

David Heiko Kolf-2
In reply to this post by nobody
Am 20.06.2019 um 15:33 schrieb nobody:

> On 20/06/2019 13.19, David Heiko Kolf wrote:
>> In C# the last error is reported and I actually think that is the
>> right decision.
>>
>> […]
>>
>> If the first error is reported I will never even know that there was a
>> second error. And once I fixed the first error, I probably won't see
>> that there is problem with my __close function.
>
> The situation that caused the last error is potentially caused by an
> arbitrarily large number of (mis-/un-)handled errors that happened
> before that, and the data that your __close has to work with is
> arbitrarily insane.  If you want to have a chance to work your way back
> to the earlier errors, you'll have to write paranoid (long, unreadable)
> code.
>
> Only the first error in the chain is certainly caused by an actual
> problem.  All later errors are potentially just interface/invariant
> violations caused by the first error, and it's not your(/__close's) job
> to navigate the mess caused by interface-/invariant-violating code.

Well, the way I learned it was that a cleanup routine just has one
well-defined job and that is to release all resources still used by the
object. So whatever happens in code outside of this object should have
no influence.

Quite the contrary, the cleanup function is supposed to get me out of
the error situation. If the situation is so messed up that I cannot
clean up resources anymore, can I still continue executing my program?
In fact, C++ seems to take this approach: if a destructor throws an
exception while another exception is already processed, it terminates
the entire application.

> How would you "fix" this "error" in your example?  I don't see anything
> wrong there.
>
>> __close = function( )  z.closed = true  end -- error, z might be nil
>
> If anything, I might add a loud check that z is a table (or
> __index-able), but Lua's error message ("attempt to index a nil value")
> already says that (and even includes the type of the value, and
> potentially its name!) – so a manual check would just add more code to
> produce a less informative error message… so actually there is nothing
> to fix?  (What am I missing? O.o)

So in my case, which was probably too artificial, the cleanup code
should first check that the objects it tries to "free" are actually
existing in the first place. Maybe this example would be more realistic:

  function mt:__close ()
    self.file_x:close()
    self.file_y:close()
  end

  function obj:open_x (name)
    self.file_x = io.open(name, "w")
  end

  function obj:open_y (name)
    self.file_y = io.open(name, "w")
  end

The object using this close function might have had file_y already
opened but there was an error before opening file_x. Now thanks to the
error raised by file_x being nil file_y will actually not be closed --
and you won't notice it and assume it is closed.

So in this case I have to test whether each of those variables had
already been assigned a value:

  function mt:__close ()
    if self.file_x then self.file_x:close() end
    if self.file_y then self.file_y:close() end
  end

Sure, you are right that someone could assign a random value that is not
a file to one of those variables. But that would be a further usage
error. First assigning one file and then assigning the next is not in
itself an error.

Best regards

David

Reply | Threaded
Open this post in threaded view
|

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

David Heiko Kolf-2
In reply to this post by Francisco Olarte
I have now done some further research in other languages, too.

C# as I already wrote returns the last error.

JavaScript also returns the last error:
<https://www.ecma-international.org/ecma-262/6.0/#sec-try-statement>

Java as you wrote returns the first error and logs all further errors:
<https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html#suppressed-exceptions>
This would be similar to the warn function, as "nobody" already
suggested in this thread earlier. (I just hope that the warn message
handler gets more flexible than it is at the moment).

C++ terminates the application once a second error happens:
<https://stackoverflow.com/questions/130117/throwing-exceptions-out-of-a-destructor>

Lua in xpcall returns "error in error handling":
  xpcall(function () error "1" end, function () error "2" end)
(Yes, that is not an exact match to __close, but still a similar case to
me).

Francisco Olarte wrote:
> IMO __close methods belong to resource/service objects, and it's no
> throw behaviour can normally be unit tested on them, giving a way to
> easily catch errors in them will lead to more difficult code in the
> well written cases and, what is worst, send a message theat "throwing
> in __close" is ok, and instigate people to write __close without care.

I agree that __close should be written very carefully but I am not sure
that ignoring errors will lead to extra careful code in general. So from
the point of view of education the C++ approach might be the best...not
sure I'd like to see that in Lua.

>> Consider this program with two errors, where at least one is a
>> programming mistake:
[...]
> That's true, but IMO a construct like that ( oportunistic closeing
> code written in the same code chunk as the mian one ) would be better
> served by one of the many ways you can simulate a try/finally.

That code was just supposed to be a short example that is easy to run in
an interpreter, the created object should resemble a real object with
resources. (In another answer in this thread I have now written a more
realistic version).

Best regards

David

Reply | Threaded
Open this post in threaded view
|

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

Francisco Olarte
David:

On Fri, Jun 21, 2019 at 9:12 PM David Heiko Kolf <[hidden email]> wrote:
>
> I have now done some further research in other languages, too.
> C# as I already wrote returns the last error.
> JavaScript also returns the last error:
> <https://www.ecma-international.org/ecma-262/6.0/#sec-try-statement>
> Java as you wrote returns the first error and logs all further errors:
> <https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html#suppressed-exceptions>

I'm nearly sure you are mixing concepts here, comparing try/finally in
C#/JavaScript with try-with-resources. They are different animals.
Java has try-finally too and it probably works similarly to its
equivalent in C#/JS ( I say probably because I don't do windows, hence
no C#, and I'm not too familiar with JS, I just know how Java works ).

I do not recall Java logging supressed exceptions ( AAMOF I would
consider this a serious fault in a serious language for serious works,
and your docs point to it just recording them and letting the
programmer handle it, which is IMHO much more correct ). Maybe if the
exception terminates the programthe outer layer prints it and logs it
fully along with any supressed component, I'm not sure as it has never
happened to me, I may try to force it )

Lua <toclose> is not like try/finally, it's like the
try-with-resources variant, which, IIRC, is the WITH in python. And
very similar to destructors in the RAII supporting languages (
CPython/Perl, which are ref-counted, or C++ and cousins ).

> This would be similar to the warn function, as "nobody" already
> suggested in this thread earlier. (I just hope that the warn message
> handler gets more flexible than it is at the moment).

I hope they do not send them there. Storing it like Java, having a
getsupressederrors() method, smething like it, may be fine, but I do
not want error descriptions forcefully polluting my warn stream ( of
course I could use an outer <toclose> to divert it, but it's not a
pretty thing ).

> C++ terminates the application once a second error happens:
> <https://stackoverflow.com/questions/130117/throwing-exceptions-out-of-a-destructor>

mmm, it's a little more complex, but basically corect, you cannot
terminate exception handling code via an exception ( You can use
exceptions, but must handle them ),and you should not let exception
leak from destructors unless declared, and it's tricky ( but using a
try { close_which_may_throw() } catch .... is kosher ) ( And the
rationale is expected, destructors run at a point where the object is
going to be destroyed, trying to allow recovery there will just
propagate around all the language and solve nothing, you need
invariants like that. If you throw and "out of space" error on a file
close ( one of the things people usually forget when using things like
STDIO, fclose() is one of the functions which may fail ), there is
little you can do to recover from it ( the file is indeterminate )).
It's very usual to find file-like classes with explciit close() which
can throw and/or  report errors which are used in the destructors with
a default handling ( of catching, logging and/or ignoring and
foloowing on ).

> Lua in xpcall returns "error in error handling":
>   xpcall(function () error "1" end, function () error "2" end)
> (Yes, that is not an exact match to __close, but still a similar case to
> me).

It should not be, IMO. That is a very specific way of doing it, more
restricted even than try/finally emulation via pcall. The message
throwing is a big sin, IMO, and it cannot be used for resource closing
as it is not even called on error.A difficult to understand error
message there seems Ok, you error in the middle of stack unwinding,
choice are very limited. It is similar to how many CPUs completely
halted on triple-faults.


> Francisco Olarte wrote:
> > IMO __close methods belong to resource/service objects, and it's no
> > throw behaviour can normally be unit tested on them, giving a way to
> > easily catch errors in them will lead to more difficult code in the
> > well written cases and, what is worst, send a message theat "throwing
> > in __close" is ok, and instigate people to write __close without care.
> I agree that __close should be written very carefully but I am not sure
> that ignoring errors will lead to extra careful code in general. So from
> the point of view of education the C++ approach might be the best...not
> sure I'd like to see that in Lua.

ALL code should be written carefully, unless explicitly noted ( like
when I post a couple of examples and say "sample code-do not rely on
it". But my point is the development process is different. <toclose>
is great for LIBRARY objects, like the builtin files, or a socket
library, which is (unit) tested, because IT CAN before incorporating
it in your application, and where you can rely on __close not
erroring. You rely on __close() not throwing as you rely on 1+1 being
2 or on socket.write sending data to the network.
For complex error handling you use try-finally or similar stuffs. Try
finally can be done but not with a patter like your xpcall sample, but
with two pcalls. You pcall the try-code and store the result ( error
or ok). Then pcall the finally code, and store it. Then you have four
outcome. When finally is ok it's easy, you error or return depending
on try result. But when finally fails you are in a weird place, and
can do many things. I normally copy the behaviour of one language I
know, say Java, because lot of smart people have spent lot of hours
thinking on it and normally I found they had godd reasons for that (
afterusing my copy of it a bit ).

The C++ approach is totally different. C++, like perl, has all the
objects scoped and with a very precise definition.The beauty of it is
you can implement nearly everything building on it. No finally? a
three lines class gives you a finally construct which you can activate
wherever you write it. No to close? write it, it's not pretty, but
it's easy. No (pythonic) with? write it. I've found that my C++ code,
once it compiles and links, is debugged pretty fast due to te strict
definition of lot of things, but it is not easy.


> > That's true, but IMO a construct like that ( oportunistic closeing
> > code written in the same code chunk as the mian one ) would be better
> > served by one of the many ways you can simulate a try/finally.
> That code was just supposed to be a short example that is easy to run in
> an interpreter, the created object should resemble a real object with
> resources. (In another answer in this thread I have now written a more
> realistic version).

Well, you totally made me think otherwise, as the code you wrote (
closing code, no access to stored state ), seemed like you totally
wanted to make an example of a double fault due to an error on a
finally clause. An "easy" way of simulating "try T finally F" in lua
would be something like (UNTESTED)
-- library
function _FINALLY_CLOSER(self) self.f(unpack(self.args)) end
_FINALLY_META = { __close = _FINALLY_CLOSER }
function FINALLY(f,...) return setmetatable(_FINALLY_META, { f=f, args={...} })
-- usage
do
  local x <toclose> = FINALLY(F)
  T()
end

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

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

David Heiko Kolf-2
Francisco Olarte wrote:
> I'm nearly sure you are mixing concepts here, comparing try/finally
> in C#/JavaScript with try-with-resources. They are different
> animals. Java has try-finally too and it probably works similarly to
> its equivalent in C#/JS ( I say probably because I don't do windows,
> hence no C#, and I'm not too familiar with JS, I just know how Java
> works ).

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.

So far I have only used finally (in any language) for cleaning up
resources, too.

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.

>> This would be similar to the warn function, as "nobody" already
>> suggested in this thread earlier. (I just hope that the warn message
>> handler gets more flexible than it is at the moment).
>
> I hope they do not send them there. Storing it like Java, having a
> getsupressederrors() method, smething like it, may be fine, but I do
> not want error descriptions forcefully polluting my warn stream

In my applications I often don't want anything on the stderr stream,
too. That's why I wrote that I hope for a more flexible warn message
handler. But whether it is an unhandled error from __gc or from __close
doesn't really matter to me, both shouldn't happen in my programs and
would be a sign of a programming error to me.

Best regards

David

Reply | Threaded
Open this post in threaded view
|

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

Francisco Olarte
David:

On Sat, Jun 22, 2019 at 11:20 AM David Heiko Kolf <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Sergey Kovalev
I wonder why method is named __toclose but not __noreference ?

сб, 22 июн. 2019 г. в 17:19, Francisco Olarte <[hidden email]>:

>
> David:
>
> On Sat, Jun 22, 2019 at 11:20 AM David Heiko Kolf <[hidden email]> 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.
>

Reply | Threaded
Open this post in threaded view
|

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

Jim-2
On Mon, Jun 24, 2019 at 09:48:39PM +0300, Sergey Kovalev wrote:
> I wonder why method is named __toclose but not __noreference ?

what about __unref(erenced) ?


Reply | Threaded
Open this post in threaded view
|

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

Jim-2

> On Mon, Jun 24, 2019 at 09:48:39PM +0300, Sergey Kovalev wrote:
> > I wonder why method is named __toclose but not __noreference ?
> what about __unref(erenced) ?

or even __destroy, __delete, __remove ?


Reply | Threaded
Open this post in threaded view
|

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

Tony Papadimitriou
I'd go with __rip which apart from a bit morbid, it's funny, memorable, and
to the point as it deals with the `death` of a variable and also keeps the
programmer rested in peace knowing there won't be problems because of what
happened :)

-----Original Message-----
From: Jim
Sent: Monday, June 24, 2019 10:32 PM
To: [hidden email]
Subject: Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors


> On Mon, Jun 24, 2019 at 09:48:39PM +0300, Sergey Kovalev wrote:
> > I wonder why method is named __toclose but not __noreference ?
> what about __unref(erenced) ?

or even __destroy, __delete, __remove ?



Reply | Threaded
Open this post in threaded view
|

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

Diego Nehab-4
How about __descope? It is a word. __enscope isn't, but we could create it if we ever wanted the converse operation.



On Mon, Jun 24, 2019 at 5:00 PM Tony Papadimitriou <[hidden email]> wrote:
I'd go with __rip which apart from a bit morbid, it's funny, memorable, and
to the point as it deals with the `death` of a variable and also keeps the
programmer rested in peace knowing there won't be problems because of what
happened :)

-----Original Message-----
From: Jim
Sent: Monday, June 24, 2019 10:32 PM
To: [hidden email]
Subject: Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors


> On Mon, Jun 24, 2019 at 09:48:39PM +0300, Sergey Kovalev wrote:
> > I wonder why method is named __toclose but not __noreference ?
> what about __unref(erenced) ?

or even __destroy, __delete, __remove ?



Reply | Threaded
Open this post in threaded view
|

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

Jim-2
In reply to this post by Tony Papadimitriou
On Mon, Jun 24, 2019 at 10:59:36PM +0300, Tony Papadimitriou wrote:
>> I wonder why method is named __toclose but not __noreference ?
>> what about __unref(erenced) ?
>> or even __destroy, __delete, __remove ?

> I'd go with __rip

which is a short and unused (?) identifier.

> which apart from a bit morbid

indeed.

what about __unused ?


Reply | Threaded
Open this post in threaded view
|

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

Jim-2
In reply to this post by Diego Nehab-4
On Mon, Jun 24, 2019 at 05:11:16PM -0300, Diego Nehab wrote:
> How about __descope? It is a word. __enscope isn't, but we could create it
> if we ever wanted the converse operation.

__not(_)in(_)use ?
__(d,g)one ?
__dead ?


12