Re: Re: Serializing exceptions

From: Date: Fri, 31 Jul 2015 22:20:58 +0000
Subject: Re: Re: Serializing exceptions
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-87464@lists.php.net to get a copy of this message
On 31 July 2015 20:56:30 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote: >Hi! > >> Personally I feel the restoring them impossible argument weak, >consider >> that we allow stuff like serializing resources without even a notice. > >Not sure what you mean by that. If you try to serialize resource, you >just get an integer. Not ideal, as a remanant of the times in PHP where >the approach was "if it doesn't make sense, do whatever and hope the >user is ok with that", but certainly it's not "serializing resources". >It's "ignoring resources when serializing and producing integers >instead". Replacing Exceptions with integers probably won't work that >well :) > >> Based on my own experiences where I had to fix multiple apps when we >> introduced the unserializable Closure (mostly error logger and >debugging >> tools) which got passed as argument in the backtrace I would prefer >if >> we could remove that restriction. > >I don't see how we can really remove the underlying problem - >Exceptions >contain backtraces, which means serializing them tries to serialize a >ton of stuff that may be not only not serializable but outright >dangerous As I have pointed out several times, it is only the 'args' section of the backtrace that ever contains unserializable items. The solution is simply not to include that argument - equivalent to setting DEBUG_BACKTRACE_IGNORE_ARGS in a debug_backtrace() call. IIRC the object of called methods is already excluded (equivalent to masking out DEBUG_PROVIDE_OBJECT) so what's left is all strings. I would have thought that genuine use cases for extracting arbitrary arguments out of an exceptions backtrace would be pretty rare. Regards, -- Rowan Collins

« previous php.internals (#87464) next »