# exception policy for core - Thread: https://externals.io/message/32833 - Original archive: https://news-web.php.net/php.internals/32833 - Started by Lukas Kahwe Smith on 2007-10-17T16:09:15+00:00 - Messages: 12 - 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 --- ## #32833 — Lukas Kahwe Smith — 2007-10-17T16:09:15+00:00 URL: https://externals.io/message/32833#32833 Hi, I remember that we discussed the question of exception throwing from core in the very early days of php 5, when the suggestion of turning all errors into exceptions first came up. I remember that we decided that exceptions should only be thrown from core on constructor errors by default. Along the lines of PDO, extensions could allow users to explicitly enable an exception mode. This popped up again as I picked up on IRC that the imagick extension is quite exception throwing happy. I do realize that this is a pecl extension, so maybe core rules do not apply (core<->pecl relations should also be addressed ASAP if you ask me). Anywas, am I remembering things correctly? Is this still our policy? If not do we have (want?) a policy? Either way, could we get a decision (or the fact that we do not want a decision) added to the coding standards? regards, Lukas --- ## #32834 — Derick Rethans — 2007-10-17T17:38:56+00:00 URL: https://externals.io/message/32833#32834 · In reply to: #32833 > Hi, > > I remember that we discussed the question of exception throwing from core in > the very early days of php 5, when the suggestion of turning all errors into > exceptions first came up. I remember that we decided that exceptions should > only be thrown from core on constructor errors by default. Along the lines of > PDO, extensions could allow users to explicitly enable an exception mode. > > This popped up again as I picked up on IRC that the imagick extension is quite > exception throwing happy. I do realize that this is a pecl extension, so maybe > core rules do not apply (core<->pecl relations should also be addressed ASAP > if you ask me). > > Anywas, am I remembering things correctly? Is this still our policy? If not do > we have (want?) a policy? In my opinion, this is still the policy that should be added to the CS. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #32855 — Marcus Boerger — 2007-10-17T20:11:45+00:00 URL: https://externals.io/message/32833#32855 · In reply to: #32834 Hello Derick, right, maybe we need writen down rules easy to read for pecl and core other then the CODING_STYLES bile. marcus Wednesday, October 17, 2007, 7:38:56 PM, you wrote: > > > […] > In my opinion, this is still the policy that should be added to the CS. > regards, > Derick > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org Best regards, Marcus --- ## #32845 — Antony Dovgal — 2007-10-18T07:45:48+00:00 URL: https://externals.io/message/32833#32845 · In reply to: #32833 > Hi, > > I remember that we discussed the question of exception throwing from > core in the very early days of php 5, when the suggestion of turning > all errors into exceptions first came up. I remember that we decided > that exceptions should only be thrown from core on constructor errors > by default. Along the lines of PDO, extensions could allow users to > explicitly enable an exception mode. First of all, I have to say that I see nothing wrong in using exceptions. Second, I see nothing wrong in using exceptions _in OO extensions_. And finally, I don't like the idea of having a special function in each and every extension to control it's error level. PDO was built this way from the very beginning, but making this some kind of standard would be a mistake IMO. You may not like exceptions, but that doesn't make them less useful. > This popped up again as I picked up on IRC that the imagick extension > is quite exception throwing happy. I do realize that this is a pecl > extension, so maybe core rules do not apply (core<->pecl relations > should also be addressed ASAP if you ask me). > > Anywas, am I remembering things correctly? Is this still our policy? > If not do we have (want?) a policy? While I agree that there should be some kind of recommendations/standards, IMO they should not include such a clause. -- Wbr, Antony Dovgal --- ## #32850 — johannes@php.net — 2007-10-18T10:29:37+00:00 URL: https://externals.io/message/32833#32850 · In reply to: #32845 Hi, > > > […] > > First of all, I have to say that I see nothing wrong in using exceptions. > Second, I see nothing wrong in using exceptions _in OO extensions_. > And finally, I don't like the idea of having a special function in each and every extension to control it's error level. > PDO was built this way from the very beginning, but making this some kind of standard would be a mistake IMO. > > You may not like exceptions, but that doesn't make them less useful. The possibility of changing the error mode at run-time makes it quite hard to read code. Since you always have to check the error mode of the object you're currently looking at. Therefore I think we should avoid adding more of these switches in future - especially on an per-object basis. johannes --- ## #32866 — Lukas Kahwe Smith — 2007-10-18T22:29:15+00:00 URL: https://externals.io/message/32833#32866 · In reply to: #32850 > Hi, > > > > […] > > The possibility of changing the error mode at run-time makes it quite > hard to read code. Since you always have to check the error mode of > the > object you're currently looking at. Therefore I think we should avoid > adding more of these switches in future - especially on an per-object > basis. Well I agree that this can be problematic. In the case of PDO one might be passing a PDO instance to various libraries, which may rely on exceptions being thrown or not. Personally I would not mind not throwing exceptions for anything but constructor errors (actually I think even those should be avoided), but that switch in PDO seemed like an acceptable balance. regards, Lukas --- ## #32868 — Larry Garfield — 2007-10-19T00:20:33+00:00 URL: https://externals.io/message/32833#32868 · In reply to: #32866 > > […] > > Well I agree that this can be problematic. In the case of PDO one > might be passing a PDO instance to various libraries, which may rely > on exceptions being thrown or not. Personally I would not mind not > throwing exceptions for anything but constructor errors (actually I > think even those should be avoided), but that switch in PDO seemed > like an acceptable balance. > > regards, > Lukas I've actually had issues in the past with PDO and non-exception error-mode handling. I had queries that were running fine but when I checked the error value it gave a non-OK value. (I forget what off hand.) As soon as I switched to exceptions, it worked perfectly. I believe this was under 5.2.1. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson --- ## #32869 — Lukas Kahwe Smith — 2007-10-19T06:39:51+00:00 URL: https://externals.io/message/32833#32869 · In reply to: #32868 > > > > […] > > I've actually had issues in the past with PDO and non-exception > error-mode > handling. I had queries that were running fine but when I checked > the error > value it gave a non-OK value. (I forget what off hand.) As soon as I > switched to exceptions, it worked perfectly. I believe this was > under 5.2.1. > > -- Well that sounds like a bug and not like a "feature" of exceptions. Or are you implying that the added complexity of this switch makes it harder to write bug free code. I do image that its a bit annoying to have to write tests to cover all the error modes. regards, Lukas --- ## #32870 — Larry Garfield — 2007-10-19T07:42:38+00:00 URL: https://externals.io/message/32833#32870 · In reply to: #32869 > > […] > > Well that sounds like a bug and not like a "feature" of exceptions. > Or are you implying that the added complexity of this switch makes it > harder to write bug free code. I do image that its a bit annoying to > have to write tests to cover all the error modes. > > regards, > Lukas I agree, although at the time I wasn't at the point where I could make a viable bug report out of it. I was writing a database wrapper layer around PDO (actually porting PDO into an existing wrapper), and did find in the end that exception-based checking, even though it never left the wrapping function I had around the actual query, made the code a lot nicer to deal with than an if-check in each case. The errors also made more sense, at least to me, than trying to get the error out of the returned error array with a variable number of entries in it. In any case, I don't find the exception usage of PDO to be a bad thing. I agree it should remain possible to use PHP without having dozens of try and catch blocks around everything, but remember that Exceptions are popular exactly because they are a clean and powerful mechanism. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson --- ## #32901 — Lukas Kahwe Smith — 2007-10-21T08:39:11+00:00 URL: https://externals.io/message/32833#32901 · In reply to: #32855 > Hello Derick, > > right, maybe we need writen down rules easy to read for pecl and > core > other then the CODING_STYLES bile. So how do you propose to proceed? What is not easy to read in the current CS? Should the note about not throwing exception for anything but constructor errors be added to the current CS? Do we bother with a CS for pecl, or do we hold off on that until something becomes a candidate to be bundled? regards, Lukas --- ## #32912 — Marcus Boerger — 2007-10-22T15:31:33+00:00 URL: https://externals.io/message/32833#32912 · In reply to: #32901 Hello Lukas, I think all pecl modules should follow the core rules and that means CODINT_STYLE should apply to pecl as much as it does to core. We should hence provide an easy to read (as in html or pdf or whatever) version that is accessible online easier and in a more prominent space than the current thing. Unless there is already something better than going to cvs.php.net or getting a CVS checkout and if so then we should provide better links to it. Especially better links on the pecl pages. marcus Sunday, October 21, 2007, 10:39:11 AM, you wrote: > > > […] > So how do you propose to proceed? What is not easy to read in the > current CS? Should the note about not throwing exception for anything > but constructor errors be added to the current CS? Do we bother with > a CS for pecl, or do we hold off on that until something becomes a > candidate to be bundled? > regards, > Lukas Best regards, Marcus --- ## #32913 — Lukas Kahwe Smith — 2007-10-22T15:51:58+00:00 URL: https://externals.io/message/32833#32913 · In reply to: #32912 > Hello Lukas, > > I think all pecl modules should follow the core rules and that means > CODINT_STYLE should apply to pecl as much as it does to core. We > should > hence provide an easy to read (as in html or pdf or whatever) > version that > is accessible online easier and in a more prominent space than the > current > thing. Unless there is already something better than going to > cvs.php.net > or getting a CVS checkout and if so then we should provide better > links to > it. Especially better links on the pecl pages. Ok, I will work on something like this next weekend. I will write it up on the wiki, but it should be easy to port that to php.net once its approved. Then again, we could just link to the file in CVS and I could instead work on improving the current document. I am still not clear what exactly you find lacking in the current document .. only that its only available in CVS? I presume that anyone working on core or pecl will have no trouble checking out that file. regards, Lukas