Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87468 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22253 invoked from network); 31 Jul 2015 23:28:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Jul 2015 23:28:39 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.169 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.160.169 mail-yk0-f169.google.com Received: from [209.85.160.169] ([209.85.160.169:34422] helo=mail-yk0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 70/C0-17913-4A40CB55 for ; Fri, 31 Jul 2015 19:28:37 -0400 Received: by ykax123 with SMTP id x123so71435002yka.1 for ; Fri, 31 Jul 2015 16:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=nNDD53r9K4CbIgXe9D6nk/mVXSR0zHKXaEQvDS2oZYg=; b=ab9RkEbFEBZeJDl90Q8szFrF5a11bBGWov0Ahyz4H6KZJ8zAW5eQ+mech8Jd7c/a2t zqilB1TYYPMweNWGyHujm48RR3xcXqGsRbqV9uGowVXf8+onnxOb1MwHdtdrQbEhe0F5 heYHJChwiX4vS/kTVRggh3LfUSKSbMlOq/zW7WFA0W947Hic7PMbrnh1kzhZx+CTC+qh 07uRdeHDQf4gc3+sepdTwZkFGOESyPHojch4qUDllG8Li1xV1Sap0oPy26f/cj49ZNlO SDQBDqMMnAfSwdZzeJ/XQO5mCyydbdwu4PqFU4BicB6I+CfvohoZqq/z5SNSuKV+MjAD WmVg== X-Received: by 10.170.137.11 with SMTP id e11mr6622969ykc.50.1438385313922; Fri, 31 Jul 2015 16:28:33 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.129.40.77 with HTTP; Fri, 31 Jul 2015 16:27:54 -0700 (PDT) In-Reply-To: References: <836BA21C-AE99-4E7B-AB06-EBC30E41BA0E@icicle.io> <0AD335F5-35F3-4D98-8F82-800A1EDF8FD8@icicle.io> <05f101d0c838$fcdab5e0$f69021a0$@belski.net> <55B63FDF.6050100@gmail.com> <55B66494.1020106@gmail.com> <55B6707A.3040405@gmail.com> Date: Sat, 1 Aug 2015 08:27:54 +0900 X-Google-Sender-Auth: sIXc_dOF865INfQHD5nVQyxZmn0 Message-ID: To: Niklas Keller Cc: Scott Arciszewski , Rowan Collins , Anthony Ferrara , PHP Internals Content-Type: multipart/alternative; boundary=001a1139f456afc77e051c342d7d Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7 From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a1139f456afc77e051c342d7d Content-Type: text/plain; charset=UTF-8 Hi Niklas, On Sat, Aug 1, 2015 at 7:20 AM, Niklas Keller wrote: > 2015-07-31 23:36 GMT+02:00 Yasuo Ohgaki : > >> Hi Niklas, >> >> On Fri, Jul 31, 2015 at 7:20 PM, Niklas Keller wrote: >> >>> Using set_error_handler isn't handling errors gracefully. Well, it's >>> better than E_ERROR, but then libraries can't handle those errors >>> gracefully, because the user might override its error handler by setting an >>> own handler. >> >> >> Now I see what do you mean by "gracefully". >> >> TL;DR; >> It's app developer jobs to handle these fatal errors. >> > > Nope. > > >> Most fatal errors shouldn't be recovered by library. e.g. Fallback to non >> CSPRNG when CSPRNG is not >> available. >> > > They should totally be handled. You need to catch the error and throw a > defined exception, otherwise your public API will break if you choose to > use another internal implementation. > Additionally, you seem to assume that the library doesn't have to do > things like cleanups in such a case. > My thought is based on Design by Contract (Contract programming). When parameter or environment does not satisfy contract, contract error should be resulted in program/process termination. Fixing inappropriate parameter or environment is not library/framework author's responsibility, but the developer's. i.e. Caller(function/programmer/system admin) has the responsibility that satisfies parameter/environment requirement. If requirement is not met, it's perfectly OK for library/framework to raise fatal errors/exceptions. e.g. "You need PHP 5.6 or greater" error. Handling these fatal errors in a library/framework make code complex unnecessarily. More complex code has more chances to have bugs including security related bugs. Library/framework may simply raise error/exception telling users "It's impossible to work". PHP is general programing language, so we have to consider long life applications such as standalone apps. I fully agree that exception is far easier for handling errors properly and keep app running. However, making randon_*() a special function does not worth it. IMHO. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a1139f456afc77e051c342d7d--