Skip to content

Use RETURN_THROWS() macro when an exception is thrown #5036

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

kocsismate
Copy link
Member

@kocsismate kocsismate commented Dec 29, 2019

Let's introduce a macro in order to indicate that an exception was thrown previously as proposed by Nikita in #4994 (review) (Click "Show resolved").

It made sense for me to use this macro even when the exception was thrown one line before, but I can also change them back to normal returns.

Copy link
Member

@nikic nikic left a comment

Choose a reason for hiding this comment

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

Would be great if we can get this used comprehensively at least for zpp return, to avoid coding style inconsistencies. Will probably take a while until this is used everywhere it should be used...

@kocsismate
Copy link
Member Author

My plan is to do the migration for ZPP and for some exceptions (after zend_type_error(), zend_value_error(), zend_throw_error(), and zend_throw_exception()) at least in Zend + the most extensions. I still have a week until my vacation ends... 😎

If you agree, I can commit the most straightforward changes directly.

@nikic
Copy link
Member

nikic commented Dec 30, 2019

Yeah, committing those directly is fine. Please add a (void) return_value; into the macro though, to make sure that it's only used in contexts that actually have a return value. That would be my main concern when it comes to mass changes.

@kocsismate
Copy link
Member Author

kocsismate commented Dec 30, 2019

Thanks for the hint, I was actually wondered how to avoid using this macro multiple times in the same code branch.

So the final version of RETURN_THROWS() should be as follows, right?
do { ZEND_ASSERT(EG(exception)); return (void) return_value; } while (0)

@nikic
Copy link
Member

nikic commented Dec 30, 2019

do { ZEND_ASSERT(EG(exception)); (void) return_value; return; } while (0)

It would be fairly unusual to return a void value, I'm not sure it's permitted at all.

@kocsismate
Copy link
Member Author

kocsismate commented Dec 30, 2019

Ok, I didn't know it's possible in this form (btw my version also worked for me).

kocsismate added a commit to kocsismate/php-src that referenced this pull request Dec 30, 2019
@php-pulls php-pulls closed this in 31cf9a7 Dec 30, 2019
@kocsismate kocsismate deleted the return-throws branch December 30, 2019 16:39
@nikic
Copy link
Member

nikic commented Jan 3, 2020

zend_fetch_resource() is another candidate for mass conversion.

@kocsismate
Copy link
Member Author

kocsismate commented Jan 3, 2020

Thanks for the idea! I was about to ask you for suggestions, so feel free to write me should a candidate come to your mind.

Would try_convert_to_string() also qualify as a good target? As far as I saw the implementation, it is, but I want to be 100% sure.

@nikic
Copy link
Member

nikic commented Jan 3, 2020

@kocsismate Yeah, try_convert_to_string() throws iff it returns null.

@kocsismate
Copy link
Member Author

Just one more question: should I also include zend_fetch_resource_ex() and zend_fetch_resource2() as well, right? They seem to be appropriate as well, but I can't determine their purpose/why they also exist.

@nikic
Copy link
Member

nikic commented Jan 3, 2020

Yes. _ex allows NULL, 2 checks for two resource types (generally persistent + non-persistent). In all cases the deciding factor whether it throws or not is whether the resource name is passed.

@kocsismate
Copy link
Member Author

Thanks!

In all cases the deciding factor whether it throws or not is whether the resource name is passed.

Yep, I noticed this after I finished the migration for zend_fetch_resource() locally, so I'll double check their name before committing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants