Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129190
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------KTCWuMFWzmxTdi3lRcOydZqE"
Message-ID: <1418f5e7-d43b-480b-b843-df9978d231c4@rwec.co.uk>
Date: Mon, 10 Nov 2025 18:53:10 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC][Discussion] use construct (Block Scoping)
Content-Language: en-GB
To: internals@lists.php.net
References: <CAFyg4HhrzQrE-q8D6WVkyq9tY+hzR=8rXiXLDPYpNKdYeydrVA@mail.gmail.com>
 <CAP1Jc105SDEmnzDbt_FoYRtnLY73H364b_JH7b5n76JOqQWzvA@mail.gmail.com>
 <4bf2e8023b934e73e0832c8dc3ddeb3c@bastelstu.be>
 <CAP1Jc130nddaoy3nnVb-RbGwbWBicc3FVykbd=T1sWzLtcy9Qg@mail.gmail.com>
 <d783142e-35a0-4f1e-b2b3-023bde0a7564@bastelstu.be>
 <CAP1Jc11O1dkMrpmZO7LasyuYUtMuzfZPEyHoac8wi7uHf=1jJw@mail.gmail.com>
In-Reply-To: <CAP1Jc11O1dkMrpmZO7LasyuYUtMuzfZPEyHoac8wi7uHf=1jJw@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------KTCWuMFWzmxTdi3lRcOydZqE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 10/11/2025 13:24, Arnaud Le Blanc wrote:
> As I'm seeing it, a File object that was explicitly closed would throw
> an exception like "FileIsClosedError". It would indicate a lifetime
> bug that needs to be fixed, not something that should be handled by
> the program. This is reasonable, as closing is a clear intent that the
> resource should not be used anymore. This is not an exception that
> needs to be handled/checked. Under these intentions, leaving the
> resource open (for the reason it's still referenced) and allowing
> writes to it would be much worse.


C# / .net has an ObjectDisposedException for this purpose. The 
documentation does indeed advise against catching it:

> In most cases, this exception results from developer error. Instead of 
> handling the error in a |try|/|catch| block, you should correct the 
> error, typically by reinstantiating the object.

https://learn.microsoft.com/en-us/dotnet/api/system.objectdisposedexception


Note that using() does not prevent this. For example, in the 
following, the using() block will implicitly call ms.Dispose(), but the 
variable is still in scope.

MemoryStream ms= new MemoryStream(16);
using (ms)
{
     ms.ReadByte();
}
ms.ReadByte(); // throws ObjectDisposedException


Similarly, additional references to the object can be made with 
lifetimes which exceed the using() block:

MemoryStream ms_outer;
using (MemoryStream ms_inner = new MemoryStream(16))
{
     ms_inner.ReadByte();
     ms_outer = ms_inner;
}
ms_outer.ReadByte(); // throws ObjectDisposedException


In Hack, I believe both of these would be rejected by the compiler, 
because any object implementing IDisposable is subject to strict usage 
restrictions.


-- 
Rowan Tommins
[IMSoP]

--------------KTCWuMFWzmxTdi3lRcOydZqE
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 10/11/2025 13:24, Arnaud Le Blanc
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAP1Jc11O1dkMrpmZO7LasyuYUtMuzfZPEyHoac8wi7uHf=1jJw@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">As I'm seeing it, a File object that was explicitly closed would throw
an exception like "FileIsClosedError". It would indicate a lifetime
bug that needs to be fixed, not something that should be handled by
the program. This is reasonable, as closing is a clear intent that the
resource should not be used anymore. This is not an exception that
needs to be handled/checked. Under these intentions, leaving the
resource open (for the reason it's still referenced) and allowing
writes to it would be much worse.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>C# / .net has an ObjectDisposedException for this purpose. The
      documentation does indeed advise against catching it:</p>
    <p>
      <blockquote type="cite">In most cases, this exception results from
        developer error. Instead of handling the error in a <code>try</code>/<code>catch</code>
        block, you should correct the error, typically by
        reinstantiating the object.</blockquote>
      <br>
<a class="moz-txt-link-freetext" href="https://learn.microsoft.com/en-us/dotnet/api/system.objectdisposedexception">https://learn.microsoft.com/en-us/dotnet/api/system.objectdisposedexception</a></p>
    <p><br>
    </p>
    <p>Note that using() does not prevent this. For example, in the
      following, the using() block will implicitly call ms.Dispose(),
      but the variable is still in scope.</p>
    <p>MemoryStream ms= new MemoryStream(16);<br>
      using (ms)<br>
      {<br>
          ms.ReadByte();<br>
      }<br>
      ms.ReadByte(); // throws ObjectDisposedException</p>
    <p><br>
    </p>
    <p>Similarly, additional references to the object can be made with
      lifetimes which exceed the using() block:</p>
    <p>MemoryStream ms_outer;<br>
      using (MemoryStream ms_inner = new MemoryStream(16))<br>
      {<br>
          ms_inner.ReadByte();<br>
          ms_outer = ms_inner;<br>
      }<br>
      ms_outer.ReadByte(); // throws ObjectDisposedException</p>
    <p><br>
    </p>
    <p>In Hack, I believe both of these would be rejected by the
      compiler, because any object implementing IDisposable is subject
      to strict usage restrictions.</p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------KTCWuMFWzmxTdi3lRcOydZqE--