Re: [PHP.next] Error-handling using "Error Events"

On Wed, Apr 9, 2014 at 10:33 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > Hi! > >> Good point. Perhaps the real question is: what are the use cases - real >> or perceived - for the @ operator, and how, if we were re-organising >> error and message handling in general, can they best be replaced. > > There are these major use cases for using @ as far as I can see: > > 1. Shutting up noisy function because I don't care about warnings, I > just want it to do what's possible and return failure code if it's not. > E.g. - I want to json_decode some data which may or may not be JSON, if > it doesn't decode it's ok, I'll just try something else, I don't see it > to tell me what's wrong with it because I don't care, it either works or > it doesn't. I.e. the situation where if it fails, I don't care why it > failed, I just want failure code. > > 2. Similar to the previous, but a bit different twist: if I want to > handle the error myself, in some different way than outputting a string > to the screen. > > @fopen is the frequent example for both of 1 and 2. Sometimes you want > to just ignore the file if it doesn't open. Sometimes you want to handle > it, but file pointer being false is enough to catch it. Of course, it'd > be even better if you could extract the reason *why* it failed but you > often don't want it where warning reporting system puts it. Same goes > for @unlink, @include, etc. > > 3. @$foo['bar'] - i.e. get me $foo['bar'] if it's there, null if > it's > not. Because writing isset($foo['bar'])?$foo['bar']:null each time is so > damn annoying. ?: helps in some cases but not all. > >>> Something like DomainNotFoundException, ConnectionDeniedException, >>> FileNotFoundException or whatnot. It's a nightmare if you actually >>> want to know what happened. >> The problem with such specific exceptions in this case is that different >> stream wrappers would want to throw completely different exceptions; I >> guess they could all extend a generic FileAccessException. > > Knowing what happened is very useful, however I don't think exception > hierarchy is a good way to keep this info. You very rarely would want to > do different things depending on why opening your file failed - was it a > disk error? permission? network problem? In any case, you probably would > want to log the error somewhere (here's where what happened is useful) > and move on (or bail out if the file was critically needed). Class > hierarchy is useless here, one class with good toString and maybe a > couple of other API methods would be much more useful. > > In general, my experience is that converting all common errors to > exceptions leads to a lot of code like: > > $success = true; > try { ... } > catch(Exception $e) { > $sucess = false; > } > if($success) { ... } > > which is plain ugly. Also, exceptions are expensive, so that would also > lead to a lot of boilerplate checking for conditions that otherwise > would be ignore - i.e. each time we try to open the file we'd have to > check if it exists and if it's readable and so on, to avoid expensive > exception. > @ actually works better in this case, but how it does it under the hood > is ugly, clunky and quite expensive too. If we could keep the agility of > @ while fixing the underlying ugliness and making the error still > accessible and useable when needed, that would be a great thing. That's the thing to do for PHP-Next. PHP-Next will be a gap in rethinking and rewriting some technical parts of the engine. Error and exception management is one part that can benefit from a rewrite. We could change things in way that they are not too error prone, and the change at user level is nearly invisible (e.g : rethink the '@' internal handling). Turning all errors to exceptions is a mistake IMHO. However, easing such a process for those who'd need it could be a great point. I'm adding the task to our wiki. Julien.Pauli