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

From: Date: Tue, 08 Apr 2014 23:10:26 +0000
Subject: Re: [PHP.next] Error-handling using "Error Events"
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-73643@lists.php.net to get a copy of this message
Hi, On Tue, Apr 8, 2014 at 11:53 PM, Rowan Collins <rowan.collins@gmail.com> wrote: > The infamous "shut up" operator (@) > ----------------------------------- > > No discussion of error-handling would be complete without mentioning this > little oddity, although I admit to a slight ignorance of exactly how it > works, and why it causes the compiler to skip optimisations. (e.g. > https://gist.github.com/nikic/6699370) > > One thought I had was that you could have a special syntax that could > register a high-priority "discard" pseudo-listener for a few lines of > lexical scope (hopefully that makes sense if you've read this far); > something like this: > > suppress_messages { > $fh = fopen('foo'); > } > > That wouldn't be quite the same as the current @ operator - if you replaced > fopen() with a user-defined wrapper, you'd need dynamic scope again - but it > would replace some use cases. I'm not sure if it would actually make sense > or not, but it gives you an idea of where my mind is going with the whole > "listener"/"pseudo-listener" concept. The fopen shut-up actually could be resolved much, much more elegant: make it throw *real, usable exceptions*, instead of returning a FALSE and spitting out a warning. Something like DomainNotFoundException, ConnectionDeniedException, FileNotFoundException or whatnot. It's a nightmare if you actually want to know what happened. Of course one could also just use the cURL library for http/ftp requests, but it doesn't have exceptions either... and it's a massive boilerplate together with checking every freaking curl_set_option for a FALSE return value. Marco

« previous php.internals (#73643) next »