On Apr 12, 2004, at 11:35 AM, George Schlossnagle wrote:
On Apr 12, 2004, at 2:14 PM, Sterling Hughes wrote:
John has gone ahead and committed a perfect example of where exceptions just mess things up. In the tidy extension if you try and set an unknown configuration option it throws an exception. This is not by any stretch of the imagination an unrecoverable error, but rather a simple failure. Yet, if you use tidy in a script, and it is not within a try {} catch {} block your script execution will be terminated because the configuration option could not be resolved. This is much less than desirable and probably confusing for someone who doesn't understand what an exception or why he should care.
I don't have a strong feeling about this either way, but to play devils advocate: You requested an option be set. That option could not be set because it is impossible to set a non-existent option. How do you know how someone wants to handle that error?
I assume they don't want their script to stop executing, their transactions to be rolled back and a nasty error page shown :
"Uncaught exception, could not set tabsize to 2 spaces"
That could just be my crazy assumption though.
It is. It's a hardocded portion of their app, and they made a mistake. They may not care, but it's also possible that they do. Assuming that they don't care enough to fix it seems equally crazy to me.
Could be a version mismatch with tidy, and a newer library. They develop there code, the option exists, and then someone with an older version of the library doesn't have that. Whether or not i have 4 spaces or 2 in my output is rather inconsequential. Now you deploy somewhere else and this explodes somewhere within a function and bumps the script out of a critical execution context and refuses to work.
You might argue that python or java would throw an exception in this case. For the majority of the java standard library and python code i have found this the opposite, however, even conceding that, PHP should never do this. We have the concept of warnings, in our world an error of this type does *not* terminate script execution. There are even less severe usages of warnings throughout the PHP source code, and there is no reason to convert them to exceptions. And if you don't, you still have the same inconsistencies.
The discussion was on OO code throwing exceptions. Given that there is very little OO core code in php4, I don't see a widespread conversion happening.
No, this discussion was on having exceptions thrown instead of E_WARNINGs inside OO code.
Rewind to the beginning of the discussion, the scope is not as broad as you claim.
I did. fast-forward to the end of this message, that's exactly the point john brought up.
The key point that you're missing in all this is that _you_ don't know what's a serious error and what's not. Only the developer knows. For instance, the python smtplib can throw any number of exceptions based on bad connect data or bad command responses. Is this a 'serious' error? It depends. If sending a mail is an inconsequential part of the app, maybe it's just an informational warning. It's also easy to imagine it being a very critical, non-recoverable error. The severity of the error lies entirely in the purview of the receiver.
Nothing sums this up for me better than KeyError, which is almost never fatal in my applications but which constantly bites me in the ass. Obviously your experiences may differ, which is really the whole point.
Well, you can use get() now and be happy. :)
I could, I could also catch my exceptions. There are plenty of other exceptions (casting errors, etc) that will irk me whenever I use Python.
I've probably written a considerably large amount of python and I haven't run into this rampant exception problem you talk about. Could also be the reason why I like Python more than you... ;) It makes sense that overloads would cause exceptions, as it does with type casting exceptions - remember, python is a strongly typed language, that type schiznizzle is important to them.
I'm not saying that exceptions should never be used. But, John suggested "As a matter of consistency, I would like to suggest that for those extensions which have a OO/procedural syntax that the non-fatal errors
generated by those extensions be thrown as Exceptions when called from an OO syntax."
I'm undecided on whether it's advisable to throw E_WARNINGs as exceptions. I think that all but engine-consistency-affecting E_ERRORs should be exceptions, but that's a different discussion.
I would probably agree with you on E_ERRORs.
Either i'm missing the point or we are agreeing this shouldn't be so.
You were saying that not doing this was consistent with other languages. I was saying that it was not.
Ok, then we disagree. I think its entirely inconsistent because the two systems don't map to each other, and you get plenty of cases where the two simply don't map. John is talking about *all* E_WARNINGs in OO code, and in the procedural variants, sending E_WARNINGs. The scope of E_WARNING is not in my opinion the same scope as an exception in any language, and we may just have to agree to disagree.
-sterling
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
