Dan Ackroyd wrote on 08/01/2016 18:44:
You're suggesting that we solve a problem in a way that pretty much
every other attempt to do has failed.
I'm not sure where you got the idea that I was suggesting anything of
the sort.
it's only by
encountering all of the small problems that you can realise that
although they are not perfect, exceptions allow much nicer APIs than
error checking.
I think you've completely misread what I said; here it is for reference:
I think it would be perfectly reasonable to implement a new file
handling API, which behaves like modern PHP (objects, exceptions, etc)
I am advocating *for* the use of exceptions *in that particular case*.
What I was saying, however, is that the question of how fopen() should
signal failure is not the same question as how PHP should signal
warnings. Since this discussion was about warnings, I was trying to move
the discussion away from its focus on one set of APIs.
If you forget to try/catch an exception it bubble up and fatals your
program, which is much better than continuing in an unknown error
state.
You're preaching to the choir here - I know exceptions are absolutely
the right thing in many cases, and use them lots in my own code.
I also know that they are not suited to every situation, and that "if
you don't tell me otherwise, I will halt your program" is sometimes
massive overkill.
I think we're just talking completely at cross-purposes here; I'm not
entirely sure what you thought I was advocating, but what I was actually
saying is really simple:
Exceptions are not the right solution to all the places that PHP
currently has warnings, so a simplified catch statement ("suppress
Exception") is not the right replacement for the @ operator.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
