Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67005 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19694 invoked from network); 8 Apr 2013 21:59:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Apr 2013 21:59:39 -0000 Authentication-Results: pb1.pair.com smtp.mail=zelnaga@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=zelnaga@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.181 as permitted sender) X-PHP-List-Original-Sender: zelnaga@gmail.com X-Host-Fingerprint: 74.125.82.181 mail-we0-f181.google.com Received: from [74.125.82.181] ([74.125.82.181:48378] helo=mail-we0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 42/32-06325-9CD33615 for ; Mon, 08 Apr 2013 17:59:37 -0400 Received: by mail-we0-f181.google.com with SMTP id d7so4856854wer.12 for ; Mon, 08 Apr 2013 14:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lrkhYqWBbBYBmcc6QTIpBoc5gqjZEdVPEQ0Im7fwIqI=; b=kmjG9/XePyIh+bkhWV4kUBZKOkWX35FdJUFeghTLzQ+RyCS/Fd2/II4uIwav2myioo Rg2Gy9cZ4GkoRpR93cSQL6/IjYnKA7VBbvwGZhdoP1t6G4e2ywFKyAlO6tR1ykS5CBtQ XLq741th1zstWpWfRf2Qi2MWMImjI45gG1ZNLgUBxUhybj09QIYandR2OWhSd4cNMIMU nitwDzpoe69wgsRMu8osv3V/Z01enJ7fmiOiIh30ParHvJTiFQmhodAgM2u7uXRgPx0E uTmJn7tXT+4ar/pfOka1FQAJKmGKCeCW8wg9T108cYmFlwe/r2fqh9XZlpdptAjAZ6NO h8DQ== MIME-Version: 1.0 X-Received: by 10.194.158.161 with SMTP id wv1mr34395157wjb.38.1365458374330; Mon, 08 Apr 2013 14:59:34 -0700 (PDT) Received: by 10.194.216.10 with HTTP; Mon, 8 Apr 2013 14:59:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Apr 2013 16:59:34 -0500 Message-ID: To: Madara Uchiha Cc: PHP Internals Content-Type: multipart/alternative; boundary=089e013c6ab05b8d9d04d9e08d1b Subject: Re: [PHP-DEV] trigger_error() enhancements From: zelnaga@gmail.com (Thomas Anderson) --089e013c6ab05b8d9d04d9e08d1b Content-Type: text/plain; charset=ISO-8859-1 That only addresses my first idea, however, one problem with it I see is that there's not as much fine tuned granularity with it. What if, for error produced by some functions, you wanted to display an HTML page showing the error and other errors you just wanted to silently log it to the DB or something. With catching you can just catch each function's errors and handle them as you see fit on a one off basis without unilaterally effecting how all errors are handled. Also, I think catching makes for more "linear" easier to read code. Or at least it can. You want to know how the error is handled? Just scroll down a line or two to the catch block. With error handling you can't scroll down a line or two - you have to go to the top, to the bottom, to another file, or whatever. Certainly it's possible to write hard to read code with try / catch blocks too (like if you have the whole file in a giant try block) but with set_error_handler() it's not just possible - it's almost guaranteed. On Mon, Apr 8, 2013 at 4:51 PM, Madara Uchiha wrote: > What's wrong with set_error_handler()? > http://php.net/manual/en/function.set-error-handler.php > > (Aside for the fact that any uncaught warning would be fatal). > > On Mon, Apr 8, 2013 at 11:51 PM, Thomas Anderson > wrote: > > I was thinking it'd be useful if people could switch between throwing > > exceptions and displaying errors. If throw were a function and not a > > language construct one could do $function($error) where $function was a > > string equal to either 'trigger_error' or 'throw'. But alas that's not > > possible. > > > > In lieu of that it seems like it'd be useful if maybe a new error type > > constant could be added - E_USER_THROWABLE - that'd turn trigger_error > into > > a throw. You wouldn't be able to use custom Exception classes in this > > instance but I think that'd be acceptable. ie. if you want more > versatility > > use throw. If you just want to be able to switch between error's and > thrown > > exceptions use trigger_error(). > > > > Also, I think it'd be useful if developers could specificy which line > > number and file name the error (or exception) displays > > > > For example... I was trying to implement support for > > stream_notification_callback in a custom stream wrapper. In my tests if > you > > pass a non-callable string to the built-in ftp stream via, let's say, > > fopen(), you get an error saying "failed to call user notifier" on the > > fopen() line. But with custom stream wrappers the best you can do is to > use > > trigger_error(). But that means that it's going to show not the line of > the > > fopen() but instead the line of the trigger_error(). Which is of limited > > usefulness I'd say since the trigger_error() isn't where the error > actually > > is. > > > > If a developer could control which line numbers and file names were > > displayed they could iterate through debug_backtrace() to get the actual > > line number they wanted to display. > > > > What are your thoughts? > --089e013c6ab05b8d9d04d9e08d1b--