# Are exceptions allowed in php core? - Thread: https://externals.io/message/51531 - Original archive: https://news-web.php.net/php.internals/51531 - Started by Ferenc Kovacs on 2011-02-24T09:29:45+00:00 - Messages: 57 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/51531.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #51531 — Ferenc Kovacs — 2011-02-24T09:29:45+00:00 URL: https://externals.io/message/51531#51531 Hi. it was mentioned multiple times on the list, that exceptions from php core is prohibited. do we have some documentation about this? the more detailed email on this topic was from Lukas: http://www.mail-archive.com/internals@lists.php.net/msg43237.html "Generally we have decided to leave Exceptions out of core with a few "exceptions": 1) errors in the constructor will throw an exception 2) extensions may choose to offer an Exception mode (see PDO) I never understood why we did 1), if a constructor can fail, then a factory should be used instead. But oh well. With 2) you are obviously also opening a pandoras box, that is similar to using a global error handler that turns all Notices, Warnings etc as Exception: you can easily break code that calls various libraries .. take for example passing in a PDO instance to one library which expects the normal error mode and another one that enables the Exception mode. For the most part however we can conclude that most libraries enable the Exception mode in PDO and I think you will be hard pressed to find any PDO code example that doesn't assume that the Exception mode is enabled. " every other mention about this topic is in-general prohibits the usage of exceptions. http://www.mail-archive.com/internals@lists.php.net/msg49637.html http://www.mail-archive.com/internals@lists.php.net/msg44159.html so I would like to know, that what is the current situation, and do these mails still holds true. maybe things has changed. Tyrael --- ## #62604 — Ferenc Kovacs — 2012-08-31T12:47:04+00:00 URL: https://externals.io/message/51531#62604 · In reply to: #51531 > Hi. > > it was mentioned multiple times on the list, that exceptions from php core > is prohibited. > do we have some documentation about this? > the more detailed email on this topic was from Lukas: > http://www.mail-archive.com/internals@lists.php.net/msg43237.html > > > "Generally we have decided to leave Exceptions out of core with a few > "exceptions": > > 1) errors in the constructor will throw an exception > 2) extensions may choose to offer an Exception mode (see PDO) > > I never understood why we did 1), if a constructor can fail, then a > factory should be used instead. But oh well. With 2) you are obviously also > opening a pandoras box, that is similar to using a global error handler > that turns all Notices, Warnings etc as Exception: you can easily break > code that calls various libraries .. take for example passing in a PDO > instance to one library which expects the normal error mode and another one > that enables the Exception mode. For the most part however we can conclude > that most libraries enable the Exception mode in PDO and I think you will > be hard pressed to find any PDO code example that doesn't assume that the > Exception mode is enabled. " > > every other mention about this topic is in-general prohibits the usage of > exceptions. > http://www.mail-archive.com/internals@lists.php.net/msg49637.html > http://www.mail-archive.com/internals@lists.php.net/msg44159.html > > so I would like to know, that what is the current situation, and do these > mails still holds true. > maybe things has changed. > > Tyrael > Sorry for bringing up this thread, but based on the recent mails from Derick it seems to me that there is/was some agreement that core features shouldn't throw exceptions. http://www.mail-archive.com/internals@lists.php.net/msg60631.html http://www.mail-archive.com/internals@lists.php.net/msg60635.html It was also mentioned in that thread that we already have a bunch of exceptions in spl, and some of the spl features should be in the core (or it is already in the core for example IteratorAggregate). Personally I think that OOP features should be allowed to throw Exceptions, and I think that it would still in line with the our users expectations. The only problem that I can think of is that for some stuff, we have both a procedural and an oop API, but I'm not proposing turning everything into Exceptions, but using them where appropriate. --- ## #62608 — Andrew Faulds — 2012-08-31T15:46:15+00:00 URL: https://externals.io/message/51531#62608 · In reply to: #62604 > It was also mentioned in that thread that we already have a bunch of > exceptions in spl, and some of the spl features should be in the core (or > it is already in the core for example IteratorAggregate). I personally don't see why SPL is separate from core PHP, especially since it's required. Why must the core not have OO stuff, but have non-OO stuff? > Personally I think that OOP features should be allowed to throw Exceptions, > and I think that it would still in line with the our users expectations. > The only problem that I can think of is that for some stuff, we have both a > procedural and an oop API, but I'm not proposing turning everything into > Exceptions, but using them where appropriate. > Not for PHP 5.5 (if that's happening?), but for PHP 6 I think a lot of things should become exceptions. I don't think that, personally, PHP's current error handling system is sufficient for properly handling errors. I think it's fine for warnings, notices, and deprecations. It's well suited to that kind of thing, and for that it should be kept (along with completely fatal core errors, where instantiating an object is inappropriate or impossible.) And yes, I think there should be exceptions in core PHP where appropriate But for handling actual errors, e.g. being unable to open a file, or failing to initialise something, Exceptions are far better suited to the task. Especially where the error is non-fatal and you may wish to catch it and do something else (for instance, if a file didn't exist, you could create a new one, perhaps). Also, I think PHP's keep-calm-and-carry-on attitude to some errors at the moment actually makes things harder, since it will often keep going, leaving behind some `NULL` value, when it would be much easier to debug if it stopped since then you don't have a strange undefined application state. But that's just my opinion :) -- Andrew Faulds http://ajf.me/ --- ## #62610 — Ferenc Kovacs — 2012-08-31T16:22:38+00:00 URL: https://externals.io/message/51531#62610 · In reply to: #62608 > > > > […] > I personally don't see why SPL is separate from core PHP, especially since > it's required. Why must the core not have OO stuff, but have non-OO stuff? The spl ext has exceptions all around, so if would count spl as "core", we have exceptions in the core already, so it would be ok to add more exceptions where appropriate. About OOP vs procedural: as I explained, we should still only use exceptions in the core where it is appropriate, if somebody sees a procedural api, he/she could be surprised if said api starts mixing OOP here through throwing exceptions around. On the other hand when somebody uses OOP features it would be natural for him/her that there could be exceptions on the way. > > Personally I think that OOP features should be allowed to throw > > […] > things should become exceptions. From the impression that I get from reading through the mailing list threads and the irc discussions I think that there aren't that many things that could turn into exceptions. `E_RECOVERABLE_ERROR` and probably that's it. > I don't think that, personally, PHP's current error handling system is > sufficient for properly handling errors. It is working for years, it could be improved but I wouldn't call it insufficient. > I think it's fine for warnings, notices, and deprecations. Yeah, continuing the execution and still being to handle/log multiple notices is something that wouldn't be possible with exceptions. > It's well suited to that kind of thing, and for that it should be kept > (along with completely fatal core errors, where instantiating an object is > inappropriate or impossible.) And yes, I think there should be exceptions > in core PHP where appropriate > Agree on both cases, but please don't turn this thread into discussing the viability of turning the php current error handling into exceptions, we have threads for that. This thread is about whether or not it is fine for a (new)core feature to throw exceptions if appropriate. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #62611 — Anthony Ferrara — 2012-08-31T17:03:15+00:00 URL: https://externals.io/message/51531#62611 · In reply to: #62610 Ferenc, > > […] > > > From the impression that I get from reading through the mailing list > threads and the irc discussions I think that there aren't that many things > that could turn into exceptions. > `E_RECOVERABLE_ERROR` and probably that's it. Actually, from my look at it, almost all E_WARNINGs, a number of E_NOTICEs (the ones that make sense to transition, like array to string cast), E_RECOVERABLE and certain `E_ERROR` (such as call to undefined method, etc) can be turned pretty easily. The ones that can't (without significant change to the engine at least) are deeper E_ERROR, E_CORE_*, and E_PARSE... Take a look at the library I am linking to deeper down. All of those errors are core thrown errors that can be easily turned into exceptions. Plus the `E_ERROR` that I couldn't, but we can in core (again, call to undefined method, etc)... > > […] > > > It is working for years, it could be improved but I wouldn't call it > insufficient. Any system where it's **harder** to handle the error properly than to ignore it is insufficient in my book. The fact that you need something like this: https://github.com/ircmaxell/ErrorExceptions to handle errors properly as exceptions (to be notified not that an error occured, but the type of error) is indicative of that... Anthony --- ## #62612 — Ferenc Kovacs — 2012-08-31T17:07:12+00:00 URL: https://externals.io/message/51531#62612 · In reply to: #62611 On Fri, Aug 31, 2012 at 7:03 PM, Anthony Ferrara wrote: > Ferenc, > > > […] > > > Actually, from my look at it, almost all E_WARNINGs, a number of E_NOTICEs > (the ones that make sense to transition, like array to string cast), > E_RECOVERABLE and certain `E_ERROR` (such as call to undefined method, etc) > can be turned pretty easily. The ones that can't (without significant > change to the engine at least) are deeper E_ERROR, E_CORE_*, and E_PARSE... > > Take a look at the library I am linking to deeper down. All of those > errors are core thrown errors that can be easily turned into exceptions. > Plus the `E_ERROR` that I couldn't, but we can in core (again, call to > undefined method, etc)... > > > > […] > > > Any system where it's **harder** to handle the error properly than to > ignore it is insufficient in my book. The fact that you need something like > this: https://github.com/ircmaxell/ErrorExceptions to handle errors > properly as exceptions (to be notified not that an error occured, but the > type of error) is indicative of that... > > Anthony > sigh. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #62614 — Stas Malyshev — 2012-08-31T17:31:05+00:00 URL: https://externals.io/message/51531#62614 · In reply to: #62610 Hi! > The spl ext has exceptions all around, so if would count spl as "core", we > have exceptions in the core already, so it would be ok to add more > exceptions where appropriate. SPL is not a part of basic language syntax. There are no SPL keywords and no SPL classes used unless you explicitly instantiate those classes. So SPL is different. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #62615 — Lester Caine — 2012-08-31T17:36:42+00:00 URL: https://externals.io/message/51531#62615 · In reply to: #62610 Ferenc Kovacs wrote: > > […] > > Yeah, continuing the execution and still being to handle/log multiple > notices is something that wouldn't be possible with exceptions. I think it is a matter of identify where exceptions might be appropriate. On the whole there is not a problem currently. > > […] > Agree on both cases, but please don't turn this thread into discussing the > viability of turning the php current error handling into exceptions, we > have threads for that. > This thread is about whether or not it is fine for a (new)core feature to > throw exceptions if appropriate. Once again it's the 'if appropriate' rather than 'if necessary'? Adding exceptions is another discussion, and I totally agree that in a few areas then almost anything would be better than the current errors, but simply returning an exception may not be necessary? I am feeling that we are getting to a point where there needs to be two different types of PHP. One that is basically OOP only and does not handle procedural stuff, and for us old stick in the mud's a procedural base that handles OO as it has in the past. Generators are an example of something that when left open and used via the various functions simply makes following easier than hiding everything away and just working by hidden magic. Exceptions have a place in the right layer, just as warnings would have if a function was called at the wrong point. Returning a suitable error number is just as valid as having to wrap stuff in try statements simply because the function does not actually handle an error condition? The Error handling brainstorming flagged up that the reasons for using an exception are not understood, so we need to understand when they are 'needed' rather then when 'appropriate'? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #62625 — Pierre Joye — 2012-09-01T09:34:41+00:00 URL: https://externals.io/message/51531#62625 · In reply to: #62614 hi Stas, > Hi! > > > […] > > SPL is not a part of basic language syntax. There are no SPL keywords > and no SPL classes used unless you explicitly instantiate those classes. > So SPL is different. End users do not see nor buy the difference between what is Zend/ or what is ext/spl (or other) and can't be disabled, like SPL. I really think we should consider exceptions, step by step, for the language itself, when it makes sense. And the generators RFC is one case where exceptions make sense (no cross discussion posting, only for the record here). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #62637 — Stas Malyshev — 2012-09-01T23:04:10+00:00 URL: https://externals.io/message/51531#62637 · In reply to: #62625 Hi! > > […] > > End users do not see nor buy the difference between what is Zend/ or > what is ext/spl (or other) and can't be disabled, like SPL. Of course they'd see it. Here it goes again: "There are no SPL keywords and no SPL classes used unless you explicitly instantiate those classes". You can not just write some plain PHP syntax and end up having SPL class. If you use SPL class, you must do "new SplSomeClass" or something similar. It has nothing to do with disabling. > I really think we should consider exceptions, step by step, for the > language itself, when it makes sense. And the generators RFC is one We should consider them, but we should not do it in ad-hoc manner. It doesn't work ad hoc - this is exactly what keeps giving PHP users grief and PHP as a project reputation of environment that makes no sense - introducing stuff in random places without regard to how other parts of the language work. Why this piece has exceptions and that doesn't? Oh, that's because one guy implemented that part, another guy implemented this, they didn't want to get to agreement on this, so they just did completely different things in two places. And how the user is expected to work with both? Well, not anybody's problem, each guy got his piece committed, written in his favorite style, matching his unique use case, and couldn't care less about anything else. This is not how language environment should be properly designed. When (and if) we have a model of using exceptions in core, then we can introduce them in core, but introducing them piecemeal in random places just because people fell like it, without any plan or design is just not right. We have to stop doing it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #62638 — Lester Caine — 2012-09-01T23:43:54+00:00 URL: https://externals.io/message/51531#62638 · In reply to: #62637 Stas Malyshev wrote: > Well, not anybody's problem, each guy got his piece > committed, written in his favorite style, matching his unique use case, > and couldn't care less about anything else. Sounds about right ... I'm doing it this way and everybody has voted that it's OK so go whistle? And we have another 'use' that makes removing exceptions even more difficult. This needs to be PLANNED, and documented fully ... not just bolted in because someone thinks it's a good idea! Look at the whole picture rather than adding piecemeal changes which then 'dictate' that other inappropriate changes should happen 'to be consistent'. PHP is NOT like compiled languages and so we don't want to loose it's fundamentally different features just because someone thing it should look like X as well. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #62639 — Gustavo Lopes — 2012-09-01T23:51:49+00:00 URL: https://externals.io/message/51531#62639 · In reply to: #62637 On Sun, 02 Sep 2012 01:04:10 +0200, Stas Malyshev wrote: > > […] > > Of course they'd see it. Here it goes again: "There are no SPL keywords > and no SPL classes used unless you explicitly instantiate those > classes". You can not just write some plain PHP syntax and end up having > SPL class. If you use SPL class, you must do "new SplSomeClass" or > something similar. It has nothing to do with disabling. This is thoroughly unconvincing. Let me see if I got this: Users do not expect exceptions in the core. They distinguish the core from the rest because the core is what they interact it when they "use only PHP syntax" (itself an odd statement, but let's let it pass). This argument has at least these shortcomings: * If users do not expect exceptions in the core, they are mistaken. There are indeed exceptions in the core. See ZEND_FE_RESET and zend_interfaces.c. Of course, no evidence has been provided one way or another. * Most ext/spl classes are not prefixed. If you ask the average PHP developer to tell between Iterator, IteratorAggregate, RecursiveIterator, ArrayAccess and Serializable, which are core and which are ext/spl, I doubt many would get the answer right. Not that they should care. * In fact, if there is a unifying theme in the usage of exceptions in PHP, is that exceptions are used when OOP interfaces are involved (see Zend interfaces, SPL, DateTime and PDO -- though optional there). The core vs. non-core argument only looks attractive because there are few built-in classes in the core. To be sure, there's one important distinction between core and ext/spl. ext/spl should depend on core, not the other way around. Which has little relevance for this discussion. -- Gustavo Lopes --- ## #62640 — Rasmus Lerdorf — 2012-09-02T00:27:02+00:00 URL: https://externals.io/message/51531#62640 · In reply to: #62639 On 09/01/2012 04:51 PM, Gustavo Lopes wrote > * In fact, if there is a unifying theme in the usage of exceptions in > PHP, is that exceptions are used when OOP interfaces are involved (see > Zend interfaces, SPL, DateTime and PDO -- though optional there). The > core vs. non-core argument only looks attractive because there are few > built-in classes in the core. I think this is drifting off-topic. Whether or not a generator is an object is an implementation detail. If I write: $things = getStuff(); foreach($things as $thing) { do_some($thing); } which is very normal PHP that you see in millions of lines of code, I would not expect to have to wrap my foreach in a try/catch here. Even if I am used to exceptions and might have: $things = getStuff(); foreach($things as $thing) { try { do_some($thing); } catch (Exception $e) { echo $e->getMessage(); } } this is still going to fatal on me eventually with an uncaught exception on the foreach if, for example, I pass the generator a second time to something and it has run off the end. This is something you don't have to worry about currently and I think it will cause headaches for people when they start passing generators around. In theory I should be able to pass a generator to any existing code that takes an array without having to worry about modifying that code to catch foreach exceptions. And yes, I know it is actually a generator exception, but to the average user it will look like it is foreach throwing. -Rasmus --- ## #62641 — Stas Malyshev — 2012-09-02T00:37:50+00:00 URL: https://externals.io/message/51531#62641 · In reply to: #62639 Hi! > * If users do not expect exceptions in the core, they are mistaken. There > are indeed exceptions in the core. See ZEND_FE_RESET and > zend_interfaces.c. Of course, no evidence has been provided one way or > another. This is not right either, but that was done in 2005. We're now in 2012 and trying to make PHP a bit more orderly. > * In fact, if there is a unifying theme in the usage of exceptions in PHP, > is that exceptions are used when OOP interfaces are involved (see Zend > interfaces, SPL, DateTime and PDO -- though optional there). The core vs. > non-core argument only looks attractive because there are few built-in > classes in the core. That's not my argument. My argument is when you instantiate some class explicitly and work with it, you know you're dealing with certain API that may include exceptions. When you're using foreach(), you don't expect to wrap each foreach() into a try-catch block. But that's what is happening here. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #62643 — Gustavo Lopes — 2012-09-02T00:44:08+00:00 URL: https://externals.io/message/51531#62643 · In reply to: #62640 On Sun, 02 Sep 2012 02:27:02 +0200, Rasmus Lerdorf wrote: > On 09/01/2012 04:51 PM, Gustavo Lopes wrote > > > […] > > I think this is drifting off-topic. Whether or not a generator is an > object is an implementation detail. My message is certainly on-topic for this thread. But you are right in that correct line of inquiry for the generator error condition is whether an exception/fatal error is appropriate in this situation, not whether exceptions are allowed in the core. For the reasons I explain next, I think it is. > $things = getStuff(); > foreach($things as $thing) { > do_some($thing); > } > > which is very normal PHP that you see in millions of lines of code, I > would not expect to have to wrap my foreach in a try/catch here. >[...] > > this is still going to fatal on me eventually with an uncaught exception > on the foreach if, for example, I pass the generator a second time to > something and it has run off the end. This is something you don't have > to worry about currently and I think it will cause headaches for people > when they start passing generators around. In theory I should be able to > pass a generator to any existing code that takes an array without having > to worry about modifying that code to catch foreach exceptions. And yes, > I know it is actually a generator exception, but to the average user it > will look like it is foreach throwing. I think the first thing anyone who uses generators must understand is that they are iterators. They should be compared with iterators, not arrays. With that in mind, the behavior is not surprising for anyone who knows how iterators and foreach interact. More importantly, there is no other satisfactory solution (except a fatal error). foreach has no return value, so it has no other way to signal a failure. If we used a notice or a warning here what would happen is that code that used generators with an invalid state would, except for the notice, work as if it had been given an empty iterator. Put another way, it would fail with only a notice, and continue. That is a far more serious problem. In other circumstances where we emit warnings, we usually have a return value the caller can check for error conditions. -- Gustavo Lopes --- ## #62644 — Gustavo Lopes — 2012-09-02T00:57:12+00:00 URL: https://externals.io/message/51531#62644 · In reply to: #62641 On Sun, 02 Sep 2012 02:37:50 +0200, Stas Malyshev wrote: > > […] > > This is not right either, but that was done in 2005. We're now in 2012 > and trying to make PHP a bit more orderly. The position that we should not use *more* exceptions in the core is of course legitimate. But let's not temper with the factual record to make an argument for it. This discussion should have started with an accurate description of the current state. > > […] > > That's not my argument. My argument is when you instantiate some class > explicitly and work with it, you know you're dealing with certain API > that may include exceptions. When you're using foreach(), you don't > expect to wrap each foreach() into a try-catch block. But that's what is > happening here. I'm not sure what you're saying that is not your argument. What you cite is an argument of mine, not yours. After that, you're basically saying the same thing as Derick -- that because you're not instantiating a class directly, you don't know that you're working with an object API that includes exceptions. I don't really have a argument for that except that users should know that generators return a sort of iterators. But in any case, the argument that you have to wrap foreach() in try-catch blocks is weak. That's like saying that in Java you have to try-catch IllegalStateExceptions all the time. The truth is, correct code will never throw these exceptions. As I explained in the reply to Rasmus' e-mail, a fatal error would also be somewhat appropriate (though inconsistent with the other Zend interfaces), but definitely a warning is not. -- Gustavo Lopes --- ## #62645 — Stas Malyshev — 2012-09-02T01:01:06+00:00 URL: https://externals.io/message/51531#62645 · In reply to: #62643 Hi! > More importantly, there is no other satisfactory solution (except a fatal > error). foreach has no return value, so it has no other way to signal a > failure. If we used a notice or a warning here what would happen is that > code that used generators with an invalid state would, except for the > notice, work as if it had been given an empty iterator. Put another way, > it would fail with only a notice, and continue. That is a far more serious > problem. In other circumstances where we emit warnings, we usually have a > return value the caller can check for error conditions. I'm not sure I understand why you think behaving as it is an empty iterator and producing an error message is "far more serious problem". Could you explain that? For me, it behaves exactly like any other iterator would behave if you had no more useful elements in it - meaning, producing no elements. I do not understand why you think it requires immediate break of the code flow and abandoning the execution of the current function - after all, for the surrounding code the situation where iterator has no elements is a normal situation for an iterator, and iterating twice is indistinguishable - from the POV of the surrounding code - from iterating an empty iterator once. Moreover, if foreach() was supposed to have any side effects, none of these effects would happen with empty return, so there's no danger here either. So I believe the point that this condition requires immediate exit from the code flow needs some explanation. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #62646 — Rasmus Lerdorf — 2012-09-02T01:07:12+00:00 URL: https://externals.io/message/51531#62646 · In reply to: #62643 > More importantly, there is no other satisfactory solution (except a > fatal error). foreach has no return value, so it has no other way to > signal a failure. If we used a notice or a warning here what would > happen is that code that used generators with an invalid state would, > except for the notice, work as if it had been given an empty iterator. > Put another way, it would fail with only a notice, and continue. That is > a far more serious problem. In other circumstances where we emit > warnings, we usually have a return value the caller can check for error > conditions. This is the real question here. It actually isn't about Exceptions at all. It is whether trying to iterate a closed generator should be a fatal error that breaks script execution right then and there. Whether that is done as an exception or a fatal error isn't actually all that relevant since the end result will be the same for most people. If everyone is in agreement that this should be a fatal error (I don't personally get why it has to be fatal) then lets just make it a fatal error and when we come up with a decent proposal for turning recoverable fatals into exceptions language-wide we can revisit this. And this might even be in the same release, so... -Rasmus --- ## #62657 — Lester Caine — 2012-09-02T08:10:28+00:00 URL: https://externals.io/message/51531#62657 · In reply to: #62646 Rasmus Lerdorf wrote: > > > […] > > This is the real question here. It actually isn't about Exceptions at > all. It is whether trying to iterate a closed generator should be a > fatal error that breaks script execution right then and there. Whether > that is done as an exception or a fatal error isn't actually all that > relevant since the end result will be the same for most people. If > everyone is in agreement that this should be a fatal error (I don't > personally get why it has to be fatal) then lets just make it a fatal > error and when we come up with a decent proposal for turning recoverable > fatals into exceptions language-wide we can revisit this. And this might > even be in the same release, so... Finally I'm understanding what my problem is with a lot of this stuff. I kept looking at this and trying to understand exactly WHAT the flow through the code is. The 'magic' processing of generators is hiding away exactly where the source of a problem is. Showing me the code that is carrying out the processing, rewind, next etc ... at lease allows me to understand just what is throwing a problem when it happens - and handling the error! And yes an exception that gives a accurate error report is the only way of handling that without the visible code steps to error against? So we are back to the fundamental problem of how does one HANDLE that exception in an environment where they are currently only used in limited specific actions ... which may also be wrong! ... I prefer to code for and capture errors, so if the file does not exist I check for that and give the user a suitable warning. If I'm iterating a file and the read does not complete becuase of an OS read fault I like to capture that state and handle it. I can accept generators IF I can bail out with a suitable error when I need to, but exceptions are there simply because no one bothered to handle the real error? The work flow has been so screwed up that the only way out is to crash? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #62658 — Gustavo Lopes — 2012-09-02T08:24:34+00:00 URL: https://externals.io/message/51531#62658 · In reply to: #62645 On Sun, 02 Sep 2012 03:01:06 +0200, Stas Malyshev wrote: > For me, it behaves exactly like any other > iterator would behave if you had no more useful elements in it - > meaning, producing no elements. I do not understand why you think it > requires immediate break of the code flow and abandoning the execution > of the current function - after all, for the surrounding code the > situation where iterator has no elements is a normal situation for an > iterator, and iterating twice is indistinguishable - from the POV of the > surrounding code - from iterating an empty iterator once. Moreover, if > foreach() was supposed to have any side effects, none of these effects > would happen with empty return, so there's no danger here either. So I > believe the point that this condition requires immediate exit from the > code flow needs some explanation. Precisely. The fact that everything happens normally except for the iterator giving out an empty set is what makes this an insidious problem. The request will be fully processed, but you will have a bug that may manifest itself in a relatively safe manners (e.g. a search page giving no results) -- though that could possibly cost a business money -- or in far more destructive manners (for instance, if the iterator was to return a set of files or database entities to keep when deleting others). -- Gustavo Lopes --- ## #62709 — Pierre Joye — 2012-09-03T08:12:46+00:00 URL: https://externals.io/message/51531#62709 · In reply to: #62637 hi! > Hi! > > > […] > > Of course they'd see it. Here it goes again: "There are no SPL keywords > and no SPL classes used unless you explicitly instantiate those > classes". You can not just write some plain PHP syntax and end up having > SPL class. If you use SPL class, you must do "new SplSomeClass" or > something similar. It has nothing to do with disabling. They are seen and promoted as core features. Whether we like that idea or not is not really relevant. We messed that up by making most of the "Standard" PHP Library an extension for only political and licensing reasons. > > […] > > We should consider them, but we should not do it in ad-hoc manner. It > doesn't work ad hoc - this is exactly what keeps giving PHP users grief > and PHP as a project reputation of environment that makes no sense - > introducing stuff in random places without regard to how other parts of > the language work. We can't really change existing code without breaking everything out there. So we somehow have to do it on a case by case basis or for new stuff only. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #62722 — Derick Rethans — 2012-09-03T11:16:34+00:00 URL: https://externals.io/message/51531#62722 · In reply to: #62643 > > > > […] > > I think the first thing anyone who uses generators must understand is that > they are iterators. You forget that not even everybody that uses PHP knows what an iterator is. For all they care, they have an array they can run foreach() on. > They should be compared with iterators, not arrays. They shouldn't be compared with either. They are magical things that happen with a "yield" keyword. > With that in mind, the behavior is not surprising for anyone who knows > how iterators and foreach interact. > > More importantly, there is no other satisfactory solution (except a fatal > error). foreach has no return value, so it has no other way to signal a > failure. If we used a notice or a warning here what would happen is that code > that used generators with an invalid state would, except for the notice, work > as if it had been given an empty iterator. Put another way, it would fail with > only a notice, and continue. Continue doing what? cheers, Derick --- ## #62734 — Lester Caine — 2012-09-03T12:40:30+00:00 URL: https://externals.io/message/51531#62734 · In reply to: #62722 Derick Rethans wrote: > > […] > You forget that not even everybody that uses PHP knows what an iterator > is. For all they care, they have an array they can run foreach() on. > > > […] > They shouldn't be compared with either. They are magical things that > happen with a "yield" keyword. Seconded ... But hiding things behind 'magic' is the problem here :( Personally for 'generators' to be any use to me I need to be able to ask them what is wrong rather than be blown out somewhere else because something unexpected happened. If it was a data stream then I'd just check $gen->error(); or $gen->noofrows to see what had happened ... nothing magic at all. But using magic necessitates exceptions since there is no other way of handling the errors? Is there no way we can 'check the state' of a generator in-line ... $gen->status for example? Surely this is just a matter of passing an 'at end of file' flag for example where you ARE reading an empty generator? Rather than just bailing out to an exception? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #62739 — Gustavo Lopes — 2012-09-03T13:12:46+00:00 URL: https://externals.io/message/51531#62739 · In reply to: #62722 Em 2012-09-03 13:16, Derick Rethans escreveu: > > […] > > You forget that not even everybody that uses PHP knows what an > iterator > is. For all they care, they have an array they can run foreach() on. > > > […] > > They shouldn't be compared with either. They are magical things that > happen with a "yield" keyword. OK, you prefer to replace the facts (generators are iterator objects and they are introduced as such) with an alternative reality that putatively exists (or will exist) in the users' mind. I have no interest in a discussion in those terms, especially (1) without any evidence indicating such mental model is widespread and (2) given that the exceptions you claim to be surprising don't happen but for a programming error (i.e. they're not exceptions that need to be caught). > > […] > > Continue doing what? > I've replied here: http://www.mail-archive.com/internals@lists.php.net/msg60706.html -- Gustavo Lopes --- ## #62763 — Stas Malyshev — 2012-09-03T21:43:55+00:00 URL: https://externals.io/message/51531#62763 · In reply to: #62709 Hi! > They are seen and promoted as core features. Whether we like that idea > or not is not really relevant. We messed that up by making most of the > "Standard" PHP Library an extension for only political and licensing > reasons. I think you using "core" here in two difference meanings, and the question of political and licensing reasons is completely irrelevant to current discussion. The question is that we have language core (keywords, syntax constructs, etc.) and we have various APIs. Unfortunately, due to disagreement among PHP developers, there's no consistent policy among APIs on the question of how to handle errors. However, there is a consistent policy about how to do it when we're talking about core PHP constructs - keywords, language syntax, etc. - that we do not use exceptions there. > We can't really change existing code without breaking everything out > there. So we somehow have to do it on a case by case basis or for new > stuff only. We have to have clear policy that can be understood by users. Doing it on a whim of a person that submits particular patch was what we were doing before, and it didn't work very well for us. The consensus by this point was that PHP keywords, language constructs, etc. do not throw exceptions (the unfortunate patch of 2005 aside). If you want to change this - fine, please propose a consistent policy that changes it, let's agree on it and adopt it. But doing it in random places just because it seemed convenient at this moment IMO is not a good idea. It is IMO exactly what we are trying to fix. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- Next page: https://externals.io/message/51531.md?page=2