# RFC: Replacing errors with Exceptions - Thread: https://externals.io/message/45070 - Original archive: https://news-web.php.net/php.internals/45070 - Started by user@domain.invalid on 2009-07-24T13:23:21+00:00 - Messages: 31 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/45070.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 --- ## #45070 — user@domain.invalid — 2009-07-24T13:23:21+00:00 URL: https://externals.io/message/45070#45070 I published a (work in progress) RFC today about replacing certain errors with exceptions. I know that there already was something similiar on the php6dev blog, but this is not completly the same, so awating your comments: http://wiki.php.net/rfc/errors_as_exceptions --- ## #45071 — troels knak-nielsen — 2009-07-24T13:37:08+00:00 URL: https://externals.io/message/45070#45071 · In reply to: #45070 > I published a (work in progress) RFC today about replacing certain > errors with exceptions. I know that there already was something similiar > on the php6dev blog, but this is not completly the same, so awating your > comments: > > http://wiki.php.net/rfc/errors_as_exceptions Maybe I'm missing the point somewhere, but isn't this as simple as installing an error-handler with set_error_handler? You can install a global handler, that throws ErrorException, if you want that. The example mentioned in the rfc - simplexml_load_file - is a bit special. If you load an invalid file, you may get more than one error. If these were converted into exceptions, you would miss all but the first. > user@domain.invalid whois -- troels --- ## #45072 — Kalle Sommer Nielsen — 2009-07-24T13:40:29+00:00 URL: https://externals.io/message/45070#45072 · In reply to: #45070 2009/7/24 : > I published a (work in progress) RFC today about replacing certain > errors with exceptions. I know that there already was something similiar > on the php6dev blog, but this is not completly the same, so awating your > comments: > > http://wiki.php.net/rfc/errors_as_exceptions > I'm a big -1, I don't see a big reason for wrapping all my code in a try/catch block when im writing flat out procedural for example, PHP isn't an OO-only language, if you need to catch such errors via exceptions you can simply do it by having a custom error handler and the ErrorException as you linked to, like: set_error_handler(function($severity, $message, $file = NULL, $line = NULL, $context = NULL) { if(!(error_reporting() & $severity)) { return; } throw new ErrorException($message, 0, $severity, $file, $line, $context); }); I don't know if PHP should adopt code into the core that can be done in less than 10 lines, however with an ini setting it might work as long its off by default, but I'm not sure how many others here are happy about adding another ini setting for this. ps. Fix your email when posting -- regrads, Kalle Sommer Nielsen kalle@php.net --- ## #45073 — Ben Scholzen 'DASPRiD' — 2009-07-24T13:43:48+00:00 URL: https://externals.io/message/45070#45073 · In reply to: #45072 To you both, this is especially, for library code like Zend Framework. The library cannot expect the user to have the error handle set, so it would have to replace the error handler before every line which it wants to try {} and reset it after the catch. This is not really a clean solution, at it can occur pretty often. Kalle Sommer Nielsen schrieb: > 2009/7/24 : > > […] > > I'm a big -1, I don't see a big reason for wrapping all my code in a > try/catch block when im writing flat out procedural for example, PHP > isn't an OO-only language, if you need to catch such errors via > exceptions you can simply do it by having a custom error handler and > the ErrorException as you linked to, like: > > set_error_handler(function($severity, $message, $file = NULL, $line = > NULL, $context = NULL) > { > if(!(error_reporting() & $severity)) > { > return; > } > > throw new ErrorException($message, 0, $severity, $file, $line, > $context); > }); > > I don't know if PHP should adopt code into the core that can be done > in less than 10 lines, however with an ini setting it might work as > long its off by default, but I'm not sure how many others here are > happy about adding another ini setting for this. > > > ps. Fix your email when posting > > -- ................................... : ___ _ ___ ___ ___ _ ___ : : | \ /_\ / __| _ \ _ (_) \ : : | |) / _ \\__ \ _/ / | |) | : : |___/_/:\_\___/_| |_|_\_|___/ : :........:........................: : Web : http://www.dasprids.de : : E-mail : mail@dasprids.de : : Jabber : jabber@dasprids.de : : ICQ : 105677955 : :........:........................: --- ## #45074 — Kalle Sommer Nielsen — 2009-07-24T13:54:20+00:00 URL: https://externals.io/message/45070#45074 · In reply to: #45073 Please don't top post 2009/7/24 Ben Scholzen 'DASPRiD' : > To you both, this is especially, for library code like Zend Framework. > The library cannot expect the user to have the error handle set, so it > would have to replace the error handler before every line which it wants > to try {} and reset it after the catch. This is not really a clean > solution, at it can occur pretty often. Then ZF should provide an error handler that can be called inside the user's error handler or simply choose to not use error handlers if the user have a custom error handler. I can't really see why the whole language should change into using exceptions by default because of something like this? -- regrads, Kalle Sommer Nielsen kalle@php.net --- ## #45075 — Ben Scholzen 'DASPRiD' — 2009-07-24T14:06:57+00:00 URL: https://externals.io/message/45070#45075 · In reply to: #45074 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kalle Sommer Nielsen wrote: > Then ZF should provide an error handler that can be called inside the > user's error handler or simply choose to not use error handlers if the > user have a custom error handler. I can't really see why the whole > language should change into using exceptions by default because of > something like this? This second suggested solution doesn't change the current behaviour at all, just adds an additional one, which under usual circumstances will never appear. Again, say for example, you have the following code: - ------------------------------ $fp = @fopen(...); if (!$fp) { // !some! error occured, handle it } - ------------------------------ I already described the problems with this in the RFC, e.g. you don't know, which error occurded, just that fopen failed. What a library currently would have to do is: - ------------------------------ function exception_error_handler($errno, $errstr, $errfile, $errline ) { throw new ErrorException($errstr, 0, $errno, $errfile, $errline); } set_error_handler('exception_error_handler'); try { $fp = fopen(…); } catch (ErrorException $e) { // Handle the exception } `restore_error_handler()`; - ------------------------------ One could surely do that, yet it is not only unneccesary much additional code, but also introduces overhead by setting and restoring the error handler again and again. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkppwAEACgkQ0HfT5Ws789DWiACgybJm1vq+Hrmtm0s1zoJ4sS0n TzoAnRtx6fT9CFn+zn8goCWByxIij6np =cmFn -----END PGP SIGNATURE --- ## #45076 — Lukas Kahwe Smith — 2009-07-24T14:26:58+00:00 URL: https://externals.io/message/45070#45076 · In reply to: #45075 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Kalle Sommer Nielsen wrote: > > […] > > This second suggested solution doesn't change the current behaviour at > all, just adds an additional one, which under usual circumstances will > never appear. > > Again, say for example, you have the following code: > > - ------------------------------ > $fp = @fopen(...); > if (!$fp) { > // !some! error occured, handle it > } > - ------------------------------ > > I already described the problems with this in the RFC, e.g. you don't > know, which error occurded, just that fopen failed. What a library > currently would have to do is: > > - ------------------------------ > function exception_error_handler($errno, $errstr, $errfile, > $errline ) { > throw new ErrorException($errstr, 0, $errno, $errfile, $errline); > } > set_error_handler('exception_error_handler'); > > try { > $fp = fopen(…); > } catch (ErrorException $e) { > // Handle the exception > } > > `restore_error_handler()`; > - ------------------------------ > > One could surely do that, yet it is not only unneccesary much > additional > code, but also introduces overhead by setting and restoring the error > handler again and again. Well this RFC suggests using Exceptions as a solution to a well known problem: In many places you cannot really handle different error conditions well, because you cannot differentiate between different error conditions (did that include fail because of a parse error or because the file is missing?) or because you are passing data to a function who's job is to validate and handle the data (simplexml example). Currently the only solution is to enable track errors and the shut up operator. Obviously that sucks. 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. So does that mean its time to open the flood gates? Contrary to what the RFC states, Exceptions are not the one error handling mechanism to rule them all. They should be used for exceptional cases, but for the most part functions/methods do fine with just returning false. Thats all people need to know most of the time. The issue is when there isn't just one possible error condition but many and as a result you want to do different things based on which ever error condition occurred. So lets take the include example. Obviously when using include, you accept the case that the file is missing (is not readable .. not quite the same, but probably the same for the purpose of this example), otherwise require would have been used. So returning false in that case makes sense. However and here we do not have an answer yet, what should be returned when the file exists but has a parse error? This I would call an exceptional case, but are these cases sufficiently relevant so that we should force Exceptions upon our general userbase? One alternative approach would be to ensure that there are simply proper validation functions, that take the guess work out of the error condition. Like for ages people have been asking to make `file_exists()` able to work with the include path. In the same vain, a method for validating an xml file could be provided. The issue is here of course that in both of these examples, doing the validation incurs significant overhead (more so in the xml case), so doing the validation beforehand would adversely affect performance (nevermind the possibility of race conditions further complicating things). So one approach would be to use the shut up operator and only call the validation method afterwards to determine the exact cause of the issue. Anyways, just pondering .. I do not really have a good solution, just trying to define the problem at hand a bit more and the some of options on the table. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #45077 — Hannes Magnusson — 2009-07-24T14:29:40+00:00 URL: https://externals.io/message/45070#45077 · In reply to: #45073 > To you both, this is especially, for library code like Zend Framework. > The library cannot expect the user to have the error handle set, so it > would have to replace the error handler before every line which it wants > to try {} and reset it after the catch. This is not really a clean > solution, at it can occur pretty often. Why do you have to replace it? You RFC says you want to throw exceptions for all E_WARNINGs - thats exactly the same as *not* restoring it. Just register errorhandler for `E_WARNING` and thats it. The libxml extension already has functionality to suppress XML errors, so your `simplexml_load_file()` example is bogus. Better example is `fopen()` on network failures, but even then I don't understand the problem. -Hannes --- ## #45078 — Alexey Zakhlestin — 2009-07-24T14:35:09+00:00 URL: https://externals.io/message/45070#45078 · In reply to: #45077 On Fri, Jul 24, 2009 at 6:29 PM, Hannes Magnusson wrote: > > > […] > > Why do you have to replace it? because in case of a library, there is a "third-party" called "user". User might have his own opinion on error-handlers. And then, there's even worse case, when there are 2 or three libraries mixed in the single project > You RFC says you want to throw exceptions for all E_WARNINGs - thats > exactly the same as *not* restoring it. > Just register errorhandler for `E_WARNING` and thats it. > > The libxml extension already has functionality to suppress XML errors, > so your `simplexml_load_file()` example is bogus. > Better example is `fopen()` on network failures, but even then I don't > understand the problem. > > > -Hannes > > -- > > > > -- Alexey Zakhlestin http://www.milkfarmsoft.com/ Sent from St Petersburg, Russian Federation --- ## #45079 — Hannes Magnusson — 2009-07-24T14:38:23+00:00 URL: https://externals.io/message/45070#45079 · In reply to: #45078 > On Fri, Jul 24, 2009 at 6:29 PM, Hannes > Magnusson wrote: > > […] > > because in case of a library, there is a "third-party" called "user". > User might have his own opinion on error-handlers. And then, there's > even worse case, when there are 2 or three libraries mixed in the > single project No. The RFC says it should throw Exception. There is no need for other error handlers in that case. If you want multiple error handlers then create RFC for error handler stacking. -Hannes --- ## #45080 — Brian Moon — 2009-07-24T15:51:02+00:00 URL: https://externals.io/message/45070#45080 · In reply to: #45073 > To you both, this is especially, for library code like Zend Framework. This tends to invalidate your entire argument IMO. Changing the core language because something is hard in an external framework that only a small percentage of actual PHP developers use is not a a good reason. > I'm a big -1, I don't see a big reason for wrapping all my code in a > try/catch block when im writing flat out procedural for example, PHP > isn't an OO-only language ++1 on that. Brian. --- ## #45081 — Matt Wilson — 2009-07-24T16:00:09+00:00 URL: https://externals.io/message/45070#45081 · In reply to: #45080 I agree, however there are certain aspects of PHP's errors that leave a lot to be desired. For instance, a failed fopen or a failed socket will often result in an uncatchable warning from php. Sure, you can add a @ to the line but that's slow and doesn't tell you anything about what happened. I've been saying for years that PHP needs to get over its perl phobia and implement something like $! fopen("file", "r") or throw new Exception("Error: ". $!); Wouldn't that be nice? > > > […] > > This tends to invalidate your entire argument IMO. Changing the > core language because something is hard in an external framework > that only a small percentage of actual PHP developers use is not a a > good reason. > > > > […] > > ++1 on that. > > Brian. --- ## #45082 — Chris Stockton — 2009-07-24T16:32:29+00:00 URL: https://externals.io/message/45070#45082 · In reply to: #45081 Sorry for top post, on my android. I disagree that php has perl phobia, but I agree that a alternative to errors needs to be made. Your example is nice but might have some tricky implementation details if php continued to throw errors when it didn't detect $!. I.E. fopen(...) or throw new CustomException($!); when custom exception writes to a log file that also writes to $! Perhaps for file not found, For example, does the first fopen throw the error or supress it as the user likely wanted. However it becomes a moot point if errors are still thrown. I agree, however there are certain aspects of PHP's errors that leave a lot to be desired. For instance, a failed fopen or a failed socket will often result in an uncatchable warning from php. Sure, you can add a @ to the line but that's slow and doesn't tell you anything about what happened. I've been saying for years that PHP needs to get over its perl phobia and implement something like $! fopen("file", "r") or throw new Exception("Error: ". $!); Wouldn't that be nice? On Jul 24, 2009, at 10:51 AM, Brian Moon wrote: > On 7/24/09 6:43 AM, Ben Scholzen 'DASPRiD' wrot... --- ## #45083 — Rasmus Lerdorf — 2009-07-24T17:23:03+00:00 URL: https://externals.io/message/45070#45083 · In reply to: #45081 Matt Wilson wrote: > I agree, however there are certain aspects of PHP's errors that leave a > lot to be desired. For instance, a failed fopen or a failed socket will > often result in an uncatchable warning from php. Sure, you can add a @ > to the line but that's slow and doesn't tell you anything about what > happened. > > I've been saying for years that PHP needs to get over its perl phobia > and implement something like $! > > fopen("file", "r") or throw new Exception("Error: ". $!); > > Wouldn't that be nice? I don't see the big difference between that and: if(!fopen("file", "r")) throw new Exception(); and `error_get_last()` gives you the type, error message, line number, and filename which you can access in your catch block. Presumably you still want to log these which you get for free so no need for the @. -Rasmus --- ## #45084 — Markus Fischer — 2009-07-24T17:44:56+00:00 URL: https://externals.io/message/45070#45084 · In reply to: #45070 Hello, user@domain.invalid wrote: > I published a (work in progress) RFC today about replacing certain > errors with exceptions. I know that there already was something similiar > on the php6dev blog, but this is not completly the same, so awating your > comments: > > http://wiki.php.net/rfc/errors_as_exceptions One of the headlines reads "Proposal and Patch", but I can't find the patch? regards, - Markus --- ## #45099 — Richard Lynch — 2009-07-27T02:40:33+00:00 URL: https://externals.io/message/45070#45099 · In reply to: #45073 > To you both, this is especially, for library code like Zend Framework. > The library cannot expect the user to have the error handle set, so it > would have to replace the error handler before every line which it > wants > to try {} and reset it after the catch. This is not really a clean > solution, at it can occur pretty often. If your library users can't set an error handler before loading Zend Framework, they have no business using Zend Framework. :-) I know for sure Exceptions aren't going into core PHP. Whether you can/should convince the simple_xml extension developer to convert or not, I dunno. -- Some people ask for gifts here. I just want you to buy an Indie CD for yourself: http://cdbaby.com/search/from/lynch --- ## #45101 — Richard Lynch — 2009-07-27T02:44:16+00:00 URL: https://externals.io/message/45070#45101 · In reply to: #45078 > On Fri, Jul 24, 2009 at 6:29 PM, Hannes > Magnusson wrote: > > […] > > because in case of a library, there is a "third-party" called "user". > User might have his own opinion on error-handlers. And then, there's > even worse case, when there are 2 or three libraries mixed in the > single project Construct your error-handler to "stack" nicely and throw or trigger_error whatever would have happened without it. Then you need not unset/reset the silly thing. -- Some people ask for gifts here. I just want you to buy an Indie CD for yourself: http://cdbaby.com/search/from/lynch --- ## #45100 — Richard Lynch — 2009-07-27T02:45:59+00:00 URL: https://externals.io/message/45070#45100 · In reply to: #45081 > I agree, however there are certain aspects of PHP's errors that leave > a lot to be desired. For instance, a failed fopen or a failed socket > will often result in an uncatchable warning from php. Sure, you can > add a @ to the line but that's slow and doesn't tell you anything > about what happened. > > I've been saying for years that PHP needs to get over its perl phobia > and implement something like $! > > fopen("file", "r") or throw new Exception("Error: ". $!); > > Wouldn't that be nice? No, it wouldn't. wtf is $! supposed to mean?! I don't want to know, actually. If I wanted to use a language that looks like a cat died on my keyboard, I'd just switch to perl. -- Some people ask for gifts here. I just want you to buy an Indie CD for yourself: http://cdbaby.com/search/from/lynch --- ## #45130 — Alban — 2009-07-29T21:33:18+00:00 URL: https://externals.io/message/45070#45130 · In reply to: #45070 Le Fri, 24 Jul 2009 15:23:21 +0200, user a écrit : > I published a (work in progress) RFC today about replacing certain > errors with exceptions. I know that there already was something similiar > on the php6dev blog, but this is not completly the same, so awating your > comments: > > http://wiki.php.net/rfc/errors_as_exceptions I'm agree for replacing error by exception. Even if this not a good idea, i think there is a big problem with error gesture into php. Exemple : http://fr3.php.net/manual/en/function.simplexml-load-string.php The simplexml_load_string documentation says : « Return Values Returns an object of class SimpleXMLElement with properties containing the data held within the xml document. On errors, it will return FALSE. » That's not true, on error, yes the fonction return false but simplexml_load_string return also an error on not xml formated string. The result is it's impossible to use this function without @ statement. This can be considered as a bug and change the documentation or remove the error in simplexml_load_string will fix the bug. In fact, with exception in place of error, the same problem had a simple solution with try / catch elements. Exception in place of error's make life easy for developpers because if developper want, he can do something by catching exception before the program interrupt. --- ## #45131 — Brian Moon — 2009-07-29T21:46:00+00:00 URL: https://externals.io/message/45070#45131 · In reply to: #45130 > Le Fri, 24 Jul 2009 15:23:21 +0200, user a écrit : > > > […] > > I'm agree for replacing error by exception. Even if this not a good > idea, i think there is a big problem with error gesture into php. > > Exemple : > http://fr3.php.net/manual/en/function.simplexml-load-string.php A couple of people have used SimpleXML as an example of how _PHP_ errors are broken. The only thing that makes SimpleXML nice is the utter horror that the other XML parsing extensions give you. SimpleXML error handling and behavior in general is confusing. So, if you want to have a discussion about how SimpleXML is messed up, have it. But, don't lump the whole language in with it. Brian. -------- http://brian.moonspot.net/ --- ## #45132 — Joey Smith — 2009-07-29T23:39:26+00:00 URL: https://externals.io/message/45070#45132 · In reply to: #45130 > The result is it's impossible to use this function without @ statement. SimpleXML is hardly alone here, but I would imagine that if we could identify these and get bugs opened on them, there'd be very little resistance to fixing that aspect. --- ## #45135 — Hannes Magnusson — 2009-07-30T08:48:49+00:00 URL: https://externals.io/message/45070#45135 · In reply to: #45130 > Le Fri, 24 Jul 2009 15:23:21 +0200, user a écrit : > > > […] > > I'm agree for replacing error by exception. Even if this not a good idea, > i think there is a big problem with error gesture into php. > > Exemple : http://fr3.php.net/manual/en/function.simplexml-load-string.php [...] > The result is it's impossible to use this function without @ statement. Are you intentionally ignoring what I've said previously in the thread? Please stop using SimpleXML as an example. You do not need @. "); if (!$sxe) { echo "Failed loading XML\n"; foreach(libxml_get_errors() as $error) { echo "\t", $error->message; } } Outputs: Failed loading XML Blank needed here parsing XML declaration: '?>' expected Opening and ending tag mismatch: xml line 1 and broken Premature end of data in tag broken line 1 No PHP warnings at all. Again. The examples you are looking for are network issues with `fopen()`, `file_get_contents()` and such things. -Hannes --- ## #45152 — Joey Smith — 2009-07-30T18:28:37+00:00 URL: https://externals.io/message/45070#45152 · In reply to: #45135 > No PHP warnings at all. > > > Again. The examples you are looking for are network issues with > `fopen()`, `file_get_contents()` and such things. > > -Hannes Hannes, these are actually the ones I had in mind when I sent my last email - unfortunately, it's been so long since I ran into one, I can't remember how to trigger it, which is why I suggested we get bugs filed. Conceptually, it doesn't seem like it should be that hard to fix them. However, now that it's come up, I'm wondering what the costs/risks are of setting `libxml_use_internal_errors()` on by default? --- ## #45154 — Hannes Magnusson — 2009-07-30T18:37:09+00:00 URL: https://externals.io/message/45070#45154 · In reply to: #45152 > However, now that it's come up, I'm wondering what the costs/risks are > of setting `libxml_use_internal_errors()` on by default? I don't think thats a good idea. People are used to getting a warning when stuff fails, and suppressing them all of the sudden is not cool and people will waste a good chunk of time figuring out what is wrong with the script they are developing and eventually find out `libxml_use_internal_errors()` is enabled by default and they'll start flaming the list about how much we all suck. -Hannes --- ## #45156 — Markus Fischer — 2009-07-30T21:17:33+00:00 URL: https://externals.io/message/45070#45156 · In reply to: #45154 Hannes Magnusson wrote: > > > […] > > I don't think thats a good idea. > People are used to getting a warning when stuff fails, and suppressing > them all of the sudden is not cool and people will waste a good chunk > of time figuring out what is wrong with the script they are developing > and eventually find out `libxml_use_internal_errors()` is enabled by > default and they'll start flaming the list about how much we all suck. Observing the thread, I totally agree to that. In my case I've "been there, done that" and although I flamed at the beginning why I can't catch the error properly (until I found the said function :) ), you can bring the counter example too: give no `libxml_use_internal_errors()` and throwing an exception instead, you don't have to worry about some special function to flip error handling. You just know how to cope with Exceptions, not some esoteric function to be called to get some information out. - Markus --- Next page: https://externals.io/message/45070.md?page=2