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
********ly 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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.


While I agree that there should be some kind of recommendations/standards, IMO they should not include such a clause.

--
Wbr,
Antony Dovgal

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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.

johannes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hello Derick,

right, maybe we need writen down rules easy to read for pecl and core
other then the CODING_STYLES bile.

marcus

Best regards,
Marcus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Well I agree that this can be problematic. In the case of PDO one =20
might be passing a PDO instance to various libraries, which may rely =20
on exceptions being thrown or not. Personally I would not mind not =20
throwing exceptions for anything but constructor errors (actually I =20
think even those should be avoided), but that switch in PDO seemed =20
like an acceptable balance.

regards,
Lukas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php