Hi! > This email is to announce the formal opening of discussion for an RFC > to clean up the behaviour of the constructors shown by several > internal classes. > > https://wiki.php.net/rfc/internal_constructor_behaviour
I'm not sure why this RFC assumes the exception is much better than returning null. Exceptions are harder to handle (requires separate syntax construct) and they are more expensive at runtime (must create an object, collect the backtrace, etc.). Also, not catching the exception immediately usually will lead to a complete application failure (usually with an obscure error message like "internal operation failed", since displaying raw exceptions to the user can be unsafe) instead of finer-grained handling. It is a long standing tradition in PHP that operations that can be expected to fail - like fopen(), date_create(), etc. - do not produce fatal errors but instead return error values which can be checked for and handled. It is true that some SPL classes departed from that, but this IMO was not an improvement but rather an annoyance that each time you use an SPL thing you have to write it in a try/catch block. That leads to much more boilerplate code than necessary. Now I understand that PHP model of doing things may be unusual for some people that come from other language background where everything throws exceptions for any slightest reason and there's no other means of error checking. But I think we can do better rather than that and have more flexible error handling - even if it would require people to be introduced to a concept they were not familiar with before coming to PHP, such as not using exceptions for everything. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
