Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69866 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56366 invoked from network); 25 Oct 2013 14:03:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Oct 2013 14:03:25 -0000 Authentication-Results: pb1.pair.com header.from=j.boggiano@seld.be; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=j.boggiano@seld.be; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain seld.be designates 209.85.223.181 as permitted sender) X-PHP-List-Original-Sender: j.boggiano@seld.be X-Host-Fingerprint: 209.85.223.181 mail-ie0-f181.google.com Received: from [209.85.223.181] ([209.85.223.181:37870] helo=mail-ie0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/E2-40084-92A7A625 for ; Fri, 25 Oct 2013 10:03:24 -0400 Received: by mail-ie0-f181.google.com with SMTP id ar20so6613711iec.12 for ; Fri, 25 Oct 2013 07:03:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nc7TZdjkhCJD1C2VN5GO7ExqBmK/F5t/aEJZ9l2Qm14=; b=jsL+Dxd/UKYvmDSFeQaS3l+wPHYZsYBz3g8PD0yoTkvFQjRCc0rojJHpCg9dFes9KP w7NIZ+fuddnE7VqZLxoS0xYTZAeQ9VHoiZDxYh0rezahJLOaRcvnd8ur/0nzLFGQQ0E/ 5REPAwb2lb3ySWArhWzBnYfJBjjt9QA4/P7A1piunpUM8zU71ZJMLIaORZs2Rf3o5Csx /YPg8wwBTGscsAQ76xdd1hmmtlUKe+lMwb74Be7/qg9MPIeDdMXRcCVNpsfUvW4VcBYD HMU0ZZs97jPliLPh+Y3TpaaMyLbZywjaLJULSvpFLwdcfsheEtSoIZOTeU1jkI5/Pqhm j90g== X-Gm-Message-State: ALoCoQldlW4HelCtfsthfFvDysxp/AVeekuX5AHGQVZobZxfgR5bb63yOy7yUCPQgkVqTYNFirii MIME-Version: 1.0 X-Received: by 10.43.178.135 with SMTP id ow7mr5066419icc.43.1382709798018; Fri, 25 Oct 2013 07:03:18 -0700 (PDT) Received: by 10.64.208.71 with HTTP; Fri, 25 Oct 2013 07:03:17 -0700 (PDT) In-Reply-To: <7048a577d3c04532b24585f6b043f913@EXCHLONDON2013.zoo.lan> References: <52699FB5.20300@garfieldtech.com> <526A6BCC.3060502@php.net> <7048a577d3c04532b24585f6b043f913@EXCHLONDON2013.zoo.lan> Date: Fri, 25 Oct 2013 16:03:17 +0200 Message-ID: To: Richard Bradley Cc: Joe Watkins , "internals@lists.php.net" , Larry Garfield Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine From: j.boggiano@seld.be (Jordi Boggiano) On Fri, Oct 25, 2013 at 3:55 PM, Richard Bradley wrote: >> How could anything be reliant on the behaviour of a fatal error in any m= eaningful way ?? >> >> Cheers >> Joe > > In plenty of ways: for example currently frameworks can "catch" fatal err= ors using "register_shutdown_function" and display an error page to the end= user (say if there is an attempt to call a method on a null object due to = an unanticipated runtime error). > > Current frameworks might be broken if the way fatal errors work is change= d. That would be a BC break. > > See e.g. http://stackoverflow.com/questions/16284235/zend-framework-error= -page-for-php-fatal-errors/16284260#16284260 > > (This is not a vote for or against this proposal; I'm just answering the = immediate parent here.) Wouldn't this sort of use case be covered by the fact that an uncaught exception would still result in a fatal error? The only case it'd "break" is if you have a try/catch around your entire application, before you had to listen to have a shutdown handler but now your catch would catch the fatal exceptions before they bring everything down. I'd imagine that this RFC would not affect most sane cases of shutdown handlers and related "show a nice error page to users when all hell breaks loose" tricks. Cheers --=20 Jordi Boggiano @seldaek - http://nelm.io/jordi