Hi
On 8/27/22 00:17, Rowan Tommins wrote:
- I've noticed that 'unserialize()' already emits E_WARNING for some types of
error (e.g. out-of-bounds integers), so users already need to be prepared for
E_WARNING to be emitted. I've adjusted the aforementioned Notice to Warning,
but we might be
On 25 August 2022 16:06:48 BST, "Tim Düsterhus" wrote:
>- I've noticed that 'unserialize()' already emits E_WARNING for some types of
>error (e.g. out-of-bounds integers), so users already need to be prepared for
>E_WARNING to be emitted. I've adjusted the aforementioned Notice to Warning,
Hi
On 8/1/22 14:58, G. P. B. wrote:
- Add a new UnserializationFailureException extends Exception (or
whatever color the bikeshed should have). Any existing catch blocks
should still match, as Exception is more general. It would break for
ext/spl, though. Unless UnserializationFailureException
Hi
On 8/1/22 14:58, G. P. B. wrote:
During review cmb noted that using an 'Error' here might not be the best
choice, as while it is likely to be a programmer error if unserializing
fails, we do not want to educate users to catch(Error).
I probably have a very different philosophy on this as
On Fri, 29 Jul 2022 at 18:17, Tim Düsterhus wrote:
> Hi!
>
> I'm currently in the process of cleaning up the error handling of the
> new ext/random and now came across the implementation of __unserialize().
>
> Looking through the source code for existing examples I found that the
> following is
Hi!
I'm currently in the process of cleaning up the error handling of the
new ext/random and now came across the implementation of __unserialize().
Looking through the source code for existing examples I found that the
following is used:
- ext/gmp: Exception
- ext/hash: Exception
-
