The behavior is as intended. What you are seeing is an error generated during execution of autoloaded code -- that this error happens to be caused by an undefined class is only incidental. The autoloader might as well cause some other fatal error, throw an exception, cause an exit etc. It is not the job of the unserialize() function to deal with these failures (nor can it, in the general case).

Maybe it's as intended but it's not documented that way -- the docs don't event mention the word «fatal».
And even if it were documented, the fact is that anything can happen when we're unserializing. I'd say that all programmers expect unserialize() to either success or fail, not to abort the whole script -- it's a Fatal Error not an Exception (the latter would be acceptable).

nickic, can you please make a feature request out of this? At a minimum, there's a security flaw here (it's easy to sabotage a script if we can control the data that it tries to unserialize).

Serialized data was never intended to be trusted if it comes from user, this is a mistake to trust user input. For more information see https://www.owasp.org/index.php/Deserialization_of_untrusted_data

@inefedor, I know that. Thing is, there will always be someone doing it. But this «undocumented behaviour» makes the unserialize() function unpredictable. That's not good and could be avoided.