# E_RECOVERABLE_ERROR for object to string conversion - Thread: https://externals.io/message/100786 - Original archive: https://news-web.php.net/php.internals/100786 - Started by Marlies Heijkoop on 2017-09-27T12:45:15+00:00 - Messages: 2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #100786 — Marlies Heijkoop — 2017-09-27T12:45:15+00:00 URL: https://externals.io/message/100786#100786 Hi Internals, I stumbled upon a difference in behavior between PHP >=7.0 and HHVM when it comes to object-to-string conversion for objects not implementing a `__toString` which caught me by surprise. It's probably a pretty common scenario, especially for inexperienced PHP developers, as all it takes is to accidentally name your method `_toString()` or `toString()` rather than `__toString()`. When trying to use an object which does not implement a __toString(), PHP will emit an `E_RECOVERABLE_ERROR` where HHVM throws an Error. See https://3v4l.org/WtJff for a minimal example. HHVM's behavior makes more sense to me here. To me, PHP's behavior is especially unexpected if you consider the behavior in https://3v4l.org/lF7gR where PHP *does* throw a (Type)Error because of the typehint. Note this example works if you change `$a` for an instance of something with a proper `__toString()`-method. I searched through the discussions on the original 'Exceptions in the engine' RFC and couldn't find any mention of this specific case so I was wondering if anyone remembers if this was deliberately kept this way? I'm not sure if I have the skill to write a patch, I'm willing to try, but it'd be a waste of time if there is some good reason for having kept this an `E_RECOVERABLE_ERROR` I'm unaware of. Met vriendelijke groet,   Marlies Heijkoop ----- MobielWerkt BV / Belsimpel.nl   T. +31 (0)50 210 34 04 E. marlies.heijkoop@belsimpel.nl I. https://www.belsimpel.nl   Bezoekadres: Waagstraat 1 9712 JX, Groningen   Postadres: Postbus 3023 9701 DA, Groningen   Op deze e-mail is een disclaimer van toepassing, ga naar www.belsimpel.nl/disclaimer_email A disclaimer is applicable to this e-mail, please refer to www.belsimpel.nl/disclaimer_email --- ## #100787 — Christoph M. Becker — 2017-09-27T13:01:22+00:00 URL: https://externals.io/message/100786#100787 · In reply to: #100786 > Hi Internals, > > I stumbled upon a difference in behavior between PHP >=7.0 and HHVM when it comes to object-to-string conversion for objects not implementing a `__toString` which caught me by surprise. > > It's probably a pretty common scenario, especially for inexperienced PHP developers, as all it takes is to accidentally name your method `_toString()` or `toString()` rather than `__toString()`. > > When trying to use an object which does not implement a __toString(), PHP will emit an `E_RECOVERABLE_ERROR` where HHVM throws an Error. > See https://3v4l.org/WtJff for a minimal example. HHVM's behavior makes more sense to me here. > > To me, PHP's behavior is especially unexpected if you consider the behavior in https://3v4l.org/lF7gR where PHP *does* throw a (Type)Error because of the typehint. Note this example works if you change `$a` for an instance of something with a proper `__toString()`-method. > > I searched through the discussions on the original 'Exceptions in the engine' RFC and couldn't find any mention of this specific case so I was wondering if anyone remembers if this was deliberately kept this way? I'm not sure if I have the skill to write a patch, I'm willing to try, but it'd be a waste of time if there is some good reason for having kept this an `E_RECOVERABLE_ERROR` I'm unaware of. I assume that this is closely related to the fact that PHP can't throw from inside of __toString(), see and . -- Christoph M. Becker