On 6/18/2016 2:29 PM, Niklas Keller wrote:
> Which potential BC? The only thing is a catch all handler that has already
> been adjusted to PHP 7.
>
> If you catch an exception you somehow promise to handle it. If you can't
> handle it, you should rethrow it.
>
> I don't think there will be real i
Christoph Becker schrieb am Sa., 18. Juni 2016, 12:34:
> On 17.06.2016 at 19:58, Rowan Collins wrote:
>
> > On 17/06/2016 17:47, Christoph Becker wrote:
> >> If something is required, one cannot do without it, so there's only one
> >> course of action, namely to bail out. In my opinion, this is
On 17.06.2016 at 19:58, Rowan Collins wrote:
> On 17/06/2016 17:47, Christoph Becker wrote:
>> If something is required, one cannot do without it, so there's only one
>> course of action, namely to bail out. In my opinion, this is the least
>> surprising way to handle missing required files, espe
I'm +1 for this on require. I'd love to see exceptions for all file I/O
stuff (no more @fopen()!) but in all likelihood, we'd need a new API for
that to keep BC.
On Fri, Jun 17, 2016 at 1:32 PM, Niklas Keller wrote:
> >
> > If something is required, one cannot do without it, so there's only one
>
> If something is required, one cannot do without it, so there's only one
> course of action, namely to bail out.
What about gracefully bailing out, like showing that composer dependencies
have to be installed?
It's just like a method call. Usually you expect a return value, unless
there's an
On Fri, Jun 17, 2016 at 6:47 PM, Christoph Becker wrote:
>
> try {
> require $fileName;
> } catch (Error $e) {
> echo "Oops, maybe deleted? " . $e;
> }
> functionDefinedInFileName();
If anyone chooses to write this kind of code, then let them figure out
why their f
On 17/06/2016 17:47, Christoph Becker wrote:
If something is required, one cannot do without it, so there's only one
course of action, namely to bail out. In my opinion, this is the least
surprising way to handle missing required files, especially as it always
has been that way (consider the pot
On 17.06.2016 at 17:44, Niklas Keller wrote:
> 2016-06-17 11:46 GMT+02:00 Christoph Becker :
>
>> On 17.06.2016 at 10:29, Alexander Lisachenko wrote:
>>
>>> Nikita, Dmitry, ping. What do you think, shouldn't we replace all
>> possible
>>> places with Fatal Errors with correct throwing of Error ex
2016-06-17 11:46 GMT+02:00 Christoph Becker :
> On 17.06.2016 at 10:29, Alexander Lisachenko wrote:
>
> > Nikita, Dmitry, ping. What do you think, shouldn't we replace all
> possible
> > places with Fatal Errors with correct throwing of Error exceptions? In
> > this concrete case it's for "requir
On 17.06.2016 at 10:29, Alexander Lisachenko wrote:
> Nikita, Dmitry, ping. What do you think, shouldn't we replace all possible
> places with Fatal Errors with correct throwing of Error exceptions? In
> this concrete case it's for "require" operator.
>
> From what I can see Error will give us m
Nikita, Dmitry, ping. What do you think, shouldn't we replace all possible
places with Fatal Errors with correct throwing of Error exceptions? In
this concrete case it's for "require" operator.
>From what I can see Error will give us more control over the file loading
process and make it more ato
2016-06-15 22:28 GMT+03:00 Niklas Keller :
> didn't read it was planned for all file functions.
Let's restrict my first suggestion only for "require" expression for now.
So proposal is following:
Rewrite "require" to throw an Error instead of current Fatal Error if some
file can not be loaded.
Oh, just read the require example, didn't read it was planned for all file
functions.
Fleshgrinder schrieb am Mi., 15. Juni 2016, 19:57:
> On 6/15/2016 7:52 PM, Niklas Keller wrote:
> > I think it can go into 7.1. It's not a BC break, as it will still
> produce a
> > fatal error if the error isn
On 6/15/2016 7:52 PM, Niklas Keller wrote:
> I think it can go into 7.1. It's not a BC break, as it will still produce a
> fatal error if the error isn't caught.
>
file_get_contents() and friends emit an E_WARNING and not an E_ERROR or
worse. ;)
--
Richard "Fleshgrinder" Fussenegger
signatur
2016-06-15 19:38 GMT+02:00 Fleshgrinder :
> On 6/15/2016 12:27 PM, Alexander Lisachenko wrote:
> > For PHP7 we have pretty errors for almost everything, even eval can
> throw a
> > ParseError exception, but not for the require expression, because it's
> > still producing an uncatchable fatal error
On 6/15/2016 12:27 PM, Alexander Lisachenko wrote:
> For PHP7 we have pretty errors for almost everything, even eval can throw a
> ParseError exception, but not for the require expression, because it's
> still producing an uncatchable fatal errors:
>
> try {
> require('no.php');
> } catch (Thr
On 15/06/2016 11:27, Alexander Lisachenko wrote:
For PHP7 we have pretty errors for almost everything, even eval can throw a
ParseError exception, but not for the require expression
Agree that this would be good. I don't know if there's a technical
reason against it, or just that nobody's got
Hi, internals!
For PHP7 we have pretty errors for almost everything, even eval can throw a
ParseError exception, but not for the require expression, because it's
still producing an uncatchable fatal errors:
try {
require('no.php');
} catch (Throwable $e) {
echo 'Catch!';
} finally {
e
18 matches
Mail list logo
