On Fri, Aug 3, 2012 at 11:05 PM, Andrew Faulds <a...@ajf.me> wrote: > On 03/08/12 21:55, Ferenc Kovacs wrote: > > Andrew: > From your mails, it seems that you don't agree with Stan on turning > everything but fatals into exceptions[9]. > I'm really confused about that, as if we take away warnings (and by that > logic everything else which is less serious than a warning) the we would > only have the fatal errors (which we already discussed to not turn into > exceptions and you also seemed to agree[10]), E_USER > and E_RECOVERABLE_ERROR. > Is this what you propose? > > Warnings aren't "errors" as such (IMO they are little more than glorified > debugging print statements). Making them into exceptions would mean you'd > have to catch them, whilst at the moment they are loud but harmless. >
errors and warnings/notices/etc. share the same infrastructure(called error handling. :P) so it is a little bit easy to get confused when someone talks about error handling in generals by errors, or only just a subset of the error levels. > However, I think more serious errors should be exceptions. But perhaps in > PHP 6, because obviously this would break a lot of things. > okay, then it is clear. > > > My opinion (and this is what I tried to explain to you) is that it is > pretty common in the core and the bundled extensions to raise notices and > warnings left and right, and still do something, > > By that I thought you meant errors of the kind E_STRICT, not warnings. > Misunderstanding. > I was referring to notices/warnings, sorry for the confusion. But it seems from your reply that you take E_STRICT messages as errors? Why? Those can only happen on successful operations, and until 5.4, they weren't part of E_ALL, so they are the less known and less serious of all of the error levels. > > If we would turn anything less serious than E_RECOVERABLE_ERROR (so any > notice, deprecation notice, strict notice or warning)into an exception, > that would be a huuuuuuge BC break. > > Of course. I think they are something the current errors system should > remain for. It should be for that kind of thing, but proper "errors" (you > know, things going wrong, not warnings etc.) should be exceptions, I think. > Yeah, errors are meant to be explicit, hard to not notice/handle and for that description, Exceptions works just fine. > > Basically silecing errors through setting error_reporting level, custom > error handlers or the @ operator would stop working, and one should put > everything into a try-catch block to not have his code blown into his code > constantly. > > Another thing that I mentioned: even if you catch everything, there > would be some things that you couldn't do anymore. > Any method which throws notices or strict/deprecated notices or warnings > would be broken, as the execution would be halted (as the execution jumps > into the catch) which would be a major PITA to the userland developers, and > without further work, it could make the userland/engine in a more fragile > state, as the original call was interrupted but the execution still > continues from a different spot. > With the current error handling the execution either resumes after the > error handler is called, or the execution is terminates gracefully > > The current error handling provides a way to trigger multiple > errors/warnings for an operation, and allows to still return and continue > the execution. > Turning everything into exceptions would kill both of those, and without > providing something similar suite, we can't do that imo. > > So basically these are our boundaries: > > - Fatal errors can't be turned into Exceptions, but it was mentioned > multiple times, that there are some fatals, which could be turned into > E_RECOVERABLE_ERROR. > > Truly fatal errors can't become exceptions. But some fatal errors > shouldn't be fatal and are recoverable (and I think these should become > exceptions). > yeah, this is in line with what I said. ... skip the links ... To sum up my thoughts: > - "real" (i.e., things going wrong, code doing something bad) errors > should become exceptions, with the possible exception of fatal errors that > it is impossible to recover from > I think that is the further where can we go without breaking every code out there. > - notices, warnings, deprecations, etc. should stay as PHP errors, so you > can just suppress them if you want, and they don't require you to handle > them > I'm thinking about some kind of new infrastructure which would allow the developer to handle/fetch the errors locally (similar to how you can fetch the last error with error_get_last(), but with the ability to fetch multiple items and only those which were generated for a given piece of code. of course we could still keep the set_error_handler() as I see two different use case for handling warnings: 1. you want to log all errors in some other format what the log_errors and error_log ini directives provide 2. you want to get the errors/warnings in the same scope where the error occured and you want to handle that error in that context for 1, the current set_error_handler is perfect (maybe some improvements would be welcome, like having multiple handlers at the same time as we allow it for spl_autoload_register, etc.), for 2, it would be nice having a better infrastructure, currently it isn't as easy to fetch the warnings for a specific operation as it could be. > So fatal errors and notices/warnings/deprecations stay errors, everything > else becomes an exception. > > Clear? > yep. ps: in the meantime we discussed with you on IRC, and it seems that after that, you would also put E_STRICT to the warnings group. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
