Re: [PHP.next] Error-handling using "Error Events"
| From: | Marco Schuster | 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