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

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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227