On Mon, Dec 16, 2019 at 10:19 AM Dennis Birkholz <p...@dennis.birkholz.biz>
wrote:
> On 12.12.19 18:13, Nikita Popov wrote:
> > On Tue, Dec 10, 2019 at 12:03 PM Dennis Birkholz <
> p...@dennis.birkholz.biz>
> > wrote:
> >> But my just want to repeat my main concern: buildin
> >> data structures that are not serializable are a real problem for users
> >> that use serialization extensively. Maybe the solution to that problem
> >> is a method to check whether a provided object graph can be serialized
> >> (which may not be possible due to throwing an exception in __sleep() or
> >> something like that), some way to ignore unserializable elements or some
> >> way to register callback methods to handle unserializable elements.
> >>
> >
> > I'm must be missing something obvious here: Isn't this a reliable way to
> > detect whether an object graph is serializable?
> >
> > try {
> > $serialized = serialize($value);
> > } catch (\Throwable $e) {
> > // not serializable
> > }
>
> Checking whether the serialization process worked is different from
> checking beforehand whether an object graph is serializable as it makes
> it a lot easier to display a meaningful error message. Something like
> the Serializable interface in Java. But that seems to not be the PHP way
> so far, I will have to think about an RFC for a second parameter for
> serialize() that accepts a callback that can "serialize"
> objects/variables that fail to serialize themselves...
>
Could you please explain in more detail what the practical distinction
between checking beforehand and catching an exception is? It seems like the
exception should be sufficient to display a meaningful error message --
heck, it already contains an error message you can use.
Nikita
