Skip to content
This repository has been archived by the owner on Jan 8, 2020. It is now read-only.

add try/catch around statements that execute intl_is_failure() #6598

Closed
wants to merge 5 commits into from
Closed

add try/catch around statements that execute intl_is_failure() #6598

wants to merge 5 commits into from

Conversation

gkralik
Copy link
Contributor

@gkralik gkralik commented Aug 26, 2014

Since PHP 5.5.0, the configuration option 'intl.use_exceptions' is available.
When set to true, IntlException's are thrown instead of just setting a error
code, so no calls to intl_is_failure() are necessary.
Without the try/catch, the Int, Float and DateTime I18n validators hard-fail
in case 'intl.use_exceptions' is set to true.

NOTE: catching Exception (super class of IntlException), as IntlException is
not available prior to PHP 5.5.0.

refs #6312

@mwillbanks
Copy link
Contributor

You should not just catch the entire exception. I'll try and add some additional notes later. You should be able to detect the version and wrap it properly. You may want to create a new method for the call as to properly wrap it for existing behavior.

@ThaDafinser
Copy link
Contributor

@gkralik @mwillbanks there is the IntlException http://php.net/manual/en/class.intlexception.php

But it's only available PHP 5.5 +

@ThaDafinser
Copy link
Contributor

@ThaDafinser
Copy link
Contributor

Other idea (should return no warning and proper handling later extending exceptions...)

if(class_exists('IntlException') && $ex instanceof IntlException)){
    //
}

@gkralik
Copy link
Contributor Author

gkralik commented Sep 25, 2014

What's the benefit? We're throwing InvalidArgumentException anyways, so why care about whether to catch Exception or IntlException here?

@gkralik
Copy link
Contributor Author

gkralik commented Sep 25, 2014

https://github.com/ThaDafinser/zf2/blob/patch-13/library/Zend/I18n/Validator/Float.php#L130 won't work for me. get_class() expects an object parameter.

@ThaDafinser
Copy link
Contributor

@gkralik
Copy link
Contributor Author

gkralik commented Sep 25, 2014

@ThaDafinser OK, i like that. This way no exceptions get lost if they're not IntlException. Want me to update the PR?

@ThaDafinser
Copy link
Contributor

@gkralik please wait for additional feedback. To be honest i dont know if this is enough, since the old parse is gone? Have to get into again
https://github.com/zendframework/zf2/blob/release-2.3.1/library/Zend/I18n/Validator/Float.php#L112-L122

@ThaDafinser
Copy link
Contributor

Also the constanct NOT_FLOAT is not used anymore?
https://github.com/zendframework/zf2/blob/master/library/Zend/I18n/Validator/Float.php#L25

@gkralik
Copy link
Contributor Author

gkralik commented Sep 25, 2014

you're right, seems to have changed quite a lot...

@gkralik
Copy link
Contributor Author

gkralik commented Sep 25, 2014

OK, just checked that: Handling of IntlException is still necessary, see https://github.com/zendframework/zf2/blob/master/library/Zend/I18n/Validator/Float.php#L125

Int and DateTime validators are still the same and need exception handling...

@ThaDafinser
Copy link
Contributor

I think @moderndeveloperllc can help, since he rewrote it
#6373

@moderndeveloperllc
Copy link
Contributor

Someone rang? Yes, I rewrote the beast called Float because it didn't actually validate everything it should have. I should get around to Int some day when I'm feeling particularly masochistic. I probably just forgot to remove the unused constant as they were both basically the same thing. Adding try/catch seems fine with me as long as it doesn't break older versions. It doesn't mess with the actual validation logic.

Then again I'm on a rather powerful (prescribed thank you very much) painkiller at the moment, so pretty much anything sounds just fine right now :-)

@gkralik
Copy link
Contributor Author

gkralik commented Sep 25, 2014

I have rebased the PR and added the check for non-IntlException.

@gkralik
Copy link
Contributor Author

gkralik commented Sep 25, 2014

@moderndeveloperllc Actually, shouldn't we set the NOT_FLOAT error before returning false in lines 173 and 248 in Zend\I18n\Validator\Float?

throw new Exception\InvalidArgumentException($formatter->getErrorMessage());
}
} catch(\Exception $e) {
if(get_class($e) != 'IntlException'){
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you use instanceof ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. IntlException is not available prior to PHP 5.5

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is actually no problem, instanceof also works when the class doesn't exist.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, didn't know that. Will change it.

@malukenho
Copy link
Member

@gkralik This PR need to be rebased.

Gregor Kralik added 2 commits October 14, 2014 09:08
Since PHP 5.5.0, the configuration option 'intl.use_exceptions' is available.
When set to true, IntlException's are thrown instead of just setting a error
code, so no calls to intl_is_failure() are necessary.
Without the try/catch, the Int, Float and DateTime I18n validators hard-fail
in case 'intl.use_exceptions' is set to true.

NOTE: catching Exception (super class of IntlException), as IntlException is
not available prior to PHP 5.5.0.

refs #6312
@gkralik
Copy link
Contributor Author

gkralik commented Oct 14, 2014

@malukenho done.

Gregor Kralik added 2 commits October 14, 2014 16:42
instanceof even works for PHP < 5.5 where IntlException does not exist,
so use it instead of get_class().
if (intl_is_failure($formatter->getErrorCode())) {
throw new ValidatorException\InvalidArgumentException($formatter->getErrorMessage());
}
} catch(\Exception $e) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gkralik well, I think you can't use pokémon exception handler here.
What you think about use one more catch statement?

<?php
try {
    // ...
} catch (IntlException $e) {
} catch (Exception $e) {    
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good hint: only catch a specific exception type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After looking over this again, I agree. Best will be to just catch IntlException here and ignore Exception completely. It seems PHP versions < 5.5 will not choke on this.

@Ocramius Ocramius added this to the 2.4.0 milestone Dec 17, 2014
@Ocramius Ocramius self-assigned this Dec 17, 2014
@Ocramius
Copy link
Member

Will need to write tests for this one before merging.

@Ocramius Ocramius modified the milestones: 2.3.4, 2.4.0 Jan 3, 2015
Ocramius added a commit that referenced this pull request Jan 3, 2015
Ocramius added a commit that referenced this pull request Jan 3, 2015
@Ocramius Ocramius closed this in 19b8cba Jan 3, 2015
@Ocramius
Copy link
Member

Ocramius commented Jan 3, 2015

Merged, thanks @gkralik! (I added the caught IntlExceptions as $previousException when re-thrown)

master: 19b8cba
develop: 490e5c8

Ocramius added a commit that referenced this pull request Feb 2, 2015
Ocramius added a commit that referenced this pull request Feb 2, 2015
gianarb pushed a commit to zendframework/zend-i18n that referenced this pull request May 15, 2015
gianarb pushed a commit to zendframework/zend-i18n that referenced this pull request May 15, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants