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

"Sort-of-nice" to see that the debate is mainly streamlined to the @-Operator-part of the Message, which to my point of view consists of much more, having "consistency" as one major thought back in mind when it was written (so I understand it). But anyways: The "Fuck-the-Shut-Uperator" (my internal name, sorry for the locker room language) should be turned around wholly, throwing an YouTriedToIgnoreThisExceptionException (taking the real Exception as a child exception) when actually supressing some error behind, which should be an exception. Think of Java, guys. If you want to ignore and proceed (Stas, this is your use case, "It may not be important"), catch a throwable and throw it into trash (one could be so kind as to at least providing something nice as Windows often did, like "Error occoured, try again, you fool"). For those who want to know the reaon, the original exception (see Java) or it's properly designed hierarcy might DO care. As some do care about proper error handling and consistency. So thank you very much for all the good work, Rowan. Just my two cents :-) Cheers Nils 2014-04-09 22:33 GMT+02:00 Stas Malyshev <smalyshev@sugarcrm.com>: > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >