PHP7 - Uncaught TypeError - Exception.php

[neo22s]

Hello,

Hope I can explain this correctly ;)

I am testing https://github.com/open-classifieds/openclassifieds2 on PHP 7 RC 4, with Kohana 3.3.4.

Found an error on the pagination module (fixed) but while testing I made a typo on the file, provoking an exception / parseerror.

Seems a Type Hinting issue. I have fixed it for now just by replacing "Exception $e" for just "$e" on the functions declarations found at file https://github.com/kohana/core/blob/3.3/master/classes/Kohana/Kohana/Exception.php

Not really elegant but for now working. I guess Exceptions work different on PHP7? and we receive a ParseError? http://php.net/manual/en/class.parseerror.php

Let me know if I can help more. Also not sure which milestone should be assigned, but I guess this should be addressed at 3.3.X branch.

If we find any other issue while testing PHP7 we will open a new ticket. Thanks.

[neo22s]

Related:
open-classifieds/openclassifieds2#1537
#635

[acoulton]

This will be due to the change in error handling in PHP7 - http://php.net/manual/en/language.errors.php7.php

The PHP7 fix would be to change (Exception $e) to (Throwable $e) - but that won't work for earlier versions because Throwable is a new PHP7 interface.

I can't think of a cross-version compatible fix other than changing this (and any other methods with a hard typehint on Exception) to be just ($e) as you've done. If we were concerned I guess we could add defensive type checking inside the method (or with a shim) - eg if ( ! $e instanceof Exception OR $e instanceof Throwable) { // throw something else? } - but that may not be necessary.

[neo22s]

I think the easiest is what I have just done xD

I can make the pull request should I do it to branch 3.3?

[rjd22]

@acoulton @neo22s I would indeed change the typehint and add some defensive coding.

Normally a parse error would cause a fatal exception but now they also throw catchable exceptions.

[enov]

if ( ! $e instanceof Exception AND ! $e instanceof Throwable) { throw InvalidArgumentException }

[neo22s]

In each function? a bit repetitive. But I see no other issue if we all agree I will do the PR.

[rjd22]

@neo22s how many functions are we talking about?
@enov I wonder if that will work since in PHP 5.4 throwable won't exist.

[neo22s]

5 that I can see.

[rjd22]

@neo22s Most likely only 1 or 2 will need to be replaced. Only the parts that do global error handing will need the change.

[neo22s]

I do the PR on 3.3.Develop #643 I will not merge unless you see it ok ;)

[rjd22]

@neo22s do the PR on 3.4/develop. We will back merge the changes if possible. But they are API breaking so most likely the won't make it in 3.3

[neo22s]

I don't have 3.4 set up..... neither in production, latest stable is 3.3.4 which I am using.

I do not see the issue about doing it for a future 3.3.5. We only got rid of some type hinting... the API remains almost the same keeping the original functionality.

[enov]

@neo22s I am really sorry, but I wrote that line only as an example, you probably need to add a message there.

something like:

if ( ! $e instanceof Exception AND ! $e instanceof Throwable)
{
    throw InvalidArgumentException('Argument 1 passed to Kohana_Kohana_Exception::handler() must be an instance of Exception or Throwable')
}

[neo22s]

@enov you are right ;) no problem will do again. But can someone tell me where should we merge and what's the plan?

For me can be in 3.3.X but if there's no agreement I will not move forward.

thanks!

[acoulton]

On reflection I think the defensive code needs to run everywhere you took out the typehint. We don't know where end-users are calling those methods, and they could well end up wanting to call one of them with a ParseError etc.

To reduce repetition add something like Kohana_Exception::throwUnlessThrowable($e, __METHOD__) and put the implementation in that. That will also make it easier to find these in future.

If we do this in 3.3, it will break if anyone has extended those methods, because the method signature in the extension class will not be compatible. That's quite possible, I think at least a couple of our projects do that. Given it won't be triggered until the application is dealing with an exception already, it could have quite negative impact if someone has missed the need to change their extension.

I think we probably need to do it for 3.4 and accept that 3.3 does not support PHP7.

[rjd22]

@neo22s I have to agree with @acoulton 3.3 will not support PHP7 since it will need API breaking changes. We just can't risk it for the users that update Kohana by composer.

[enov]

@acoulton exactly. I was just about to write about this. Or may we add an incompatibility notice similar to the one we did in 3.3.4?

[neo22s]

@acoulton @rjd22 actually had that issue already I had extended exception and it breaks.

But I think @enov has a great point...this is been done before. Whatever you want. If just for this 3.3 is not compatible with PHP7 its a pity. no?

Are we realistic that 3.4. is ever going to be launched? that's the question...

[acoulton]

@neo22s @enov the incompatibility notice for 3.3.4 was because we had to make a breaking change to fix a security issue. It was also a straightforward 'your whole site will break immediately until you do this thing' so in the worst case people who update by composer would break everything and then go and read the docs.

Adding support for a new language version is a whole different thing and doesn't IMHO justify breaking semver especially with something that will show up some time after the upgrade.

This can't go to 3.3.

We need to make a plan to release 3.4 - there are lots of long-term ambitions for it, but there's no reason we couldn't just finish up the bits currently in progress, release, and start a 3.5 for all the rest.

In fact, with a quick bit of final testing and review we could probably even release 3.4 as-is.

[enov]

There is #524 that needs to be fixed for 3.4.

[enov]

By the way, the manual on page http://php.net/manual/en/function.set-exception-handler.php says:

This is the handler signature since PHP 7:
void handler (Throwable $ex)

How come a handler without Throwable is working?

[rjd22]

@enov Because they implement it not enforce it most likely for backwards compatibility.

[neo22s]

@enov @acoulton @rjd22 I do not mind the solution we just need one ;)

I have more than 7K sites using KO 3.3.4 and many of them are going to be happy to move to php7, I will love to be able to use 3.3.X for all of them...

I have no problem to use 3.4 but when this will be launched? will break compatibility? I've been reading about 3.4 for long time now.

For the time been I will just add the fix on our repo of open-classifeds so its php7 compatible and whenever 3.4 is launched we will absolutely update if its viable.

thanks, since this is not going to be fixed I will close the issue.

[enov]

@neo22s we all want to be able to use 3.3.x on PHP 7.0 :)

However, since we made a promise not to break on minor releases, we can not just do that for every other reason. That's what @acoulton is trying to say here, and I guess he has a point.

I will reopen this, as this is not solved, it is still an issue, we'll close once it is fully settled:

• PHP 7.0 built should be removed from Travis CI
• There should be added documentation that we do not officially support PHP 7.0 but it might be possible with some changes via CFS from the user's application side.

[neo22s]

Thanks @enov I understand all of you. Trying to help but gets really difficult.

What if we do a module that extends those classes that will break the compatibility? we could even call it php7 module...

So far only found issues on exception and pagination which is not even a kohana official module anymore.

[enov]

What if we do a module that extends those classes that will break the compatibility?

A module sounds a good compromise. Probably, we would duplicate Kohana_Kohana_Exception in there without the Exception type hints in the methods.

@acoulton @rjd22 ?

[acoulton]

Yeah an optional php7 support module would be a good stopgap, although it might need the end-user to add an explicit require 'path/to/kohana-php7/classes/kohana/kohana/exception.php at the top of their bootstrap - there may be times the exception classes are referenced before the module CFS autoload paths have been registered.

If it's a PHP7 module, it should just change the signature from (Exception $e) to (Throwable $e) since there's no need for that module to support earlier PHP versions.

[enov]

Another solution without a module would be to create Kohana_Kohana_Exception_PHP7 and duplicate Kohana_Kohana_Exception in there without the Exception type hints in the methods.

Then the user will extend it either in the application via CFS or in bootstrap.php:

if (version_compare(PHP_VERSION, '7.0.0') >= 0) {
    class Kohana_Exception extends Kohana_Kohana_Exception_PHP7 {}
}

I know that sounds hackish but I am sharing it as it's a viable solution.

[neo22s]

@acoulton you are right that issue will happen damn.

@enov nasty! love it! we should do that!! good idea ;)

[enov]

OK, this will be my last hackish proposal for today, as I will be off my dev machine for the rest of the day.

This would create additional 3 classes:

// in Kohana/Kohana/Exception.php
if (version_compare(PHP_VERSION, '7.0.0') >= 0) {
    class Kohana_Kohana_Exception extends Kohana_Kohana_Exception_PHP7 {}
} else {
    class Kohana_Kohana_Exception extends Kohana_Kohana_Exception_PHP5 {}
}

Both Kohana_Kohana_Exception_PHP5 and Kohana_Kohana_Exception_PHP7 would "decorate" (everything is static so I am not sure there will be a need for real decorator) a Kohana_Kohana_Exception_Base (Base might not be the suitable name for the class) and call its methods within the handlers that have the right signatures.

This way, it will be fully compatible with existing applications. We might have to take additional care about log tracing, as there is now more levels of trace.

So, again, another hack. You love hacks don't you? Someone shoot me. 🔫 @zombor?

[neo22s]

@enov love getting things done, no matter what ;)

[rjd22]

@enov I would not make a hack for PHP7 support. But a compatibility module sounds fine. @neo22s I would suggest you implement the fix in a module or in open-classifieds itself.

If you thinking about making it a module I would gladly add it to the kohana scope.

This issue will need to be fixed in kohana 3.4. and don't fret @neo22s you are also in the Kohana organisation so you can even make it possible to release 3.4

[neo22s]

@rjd22 I see your point but would not be more straightforward the hack? no need to explain to download the module etc.. also the module will raise issues as @acoulton says. So I now I do not see it as module.

On our software I will just replace the file for now until new release of KO.

Thanks to all ;)

Can we do a small voting?

Options would be:
1 - We do nothing, so 3.3 is not PHP7 compatible
2- We do a module, having issues when an exception happens before the module is loaded.
3- Hack exception for PHP7

[neo22s]

I vote 3

[rjd22]

I vote 1, since hack code will come back in upstream versions also.

[rjd22]

@neo22s I saw you made some PR's for 3.3 if you would make one for 3.4/develop I would gladly merge it :)

[neo22s]

@rjd22 I do not have the project set for 3.4 since we are not using it so I can not properly test it now. I can do the merge too xD I am part of the cool kids club :P https://github.com/orgs/kohana/people just don't like to add things without consensus ;) thanks!

[enov]

I am leaning towards not breaking BC for PHP 7.0 support, and not willing to continue to hack around, as it might open a door to headaches.

Someone could add a "PHP 7.0 support" page to the docs: no official support, just some ways through the CFS, with a link to this discussion.

We can keep the Travis build around, to keep the code in check, with a comment in travis.yml:

language: php

php:
  - 5.4
  - 5.5
  - 5.6
  - 7.0 # experimental, see https://github.com/kohana/core/issues/642
  - hhvm

What do you say?

[acoulton]

I vote 2.

In option 3 (magically detecting the version), then:

• someone updates now to 3.3.5 or whatever
• later they move their project to PHP7, according to composer we support it
• later still they have an error and their error handling breaks
• users see very broken stuff in production while they figure out what happened
• developers have to leave the pub, and get annoyed with us.

In option 2 (a compatibility module):

• someone updates now to 3.3.5 or whatever
• they decide they want to use PHP7
• they notice 3.3 doesn't support PHP7 out of the box, but 3.4 does (when it comes)
• they decide whether to update to 3.4, or whether to install the compatibility module
• they know they are making a breaking change in either case, so they read the upgrade notes/changelog and modify the method signatures in their own extended methods.
• their users don't have problems
• developers stay in the pub and reflect on how happy they are that we followed semver.

[neo22s]

So who makes the decision? there's 1 vote for each proposal.

any solution is better than none that for sure.

Who has the last word?

[acoulton]

I guess @shadowhand has the last word.

But it looks like there's a majority opposed to doing anything about this in standard kohana/core (for 3.3).

I still think a compatibility module is better than doing nothing (or leaving users to fix it themselves), but I think those are the remaining options.

[shadowhand]

Vote 1. Kohana 3.3 is (in software terms) ancient. PHP7 isn't even in RC yet.

[neo22s]

ok, so 1 it is, majority of votes.

We do nothing, KO 3.3 wont be PHP 7 compatible and Kohana won't work on php 7 since there's no KO 3.4. scheduled.

@shadowhand PHP 7 is in RC 5, http://php.net/archive/2015.php#id2015-10-15-2 final release planed for 12 November 2015. https://wiki.php.net/todo/php70#timetable

[shadowhand]

Well, TIL but doesn't change my opinion. Kohana has been dead for a while, despite people beating on the horse. I doubt anyone using Kohana 3.3 is going to be looking to jump on PHP 7 anytime soon.

[neo22s]

@shadowhand I do and seems some other folks too. But whatever, I respect your work you have done a lot a pity all ends up like this.

[shadowhand]

@neo22s in which case you can patch you installation without much effort. There are many (better) options available. Maybe time to buy a copy of MLAPHP.

[neo22s]

@shadowhand I will love to move the project kohana into another direction, I think I spoke about this before. And will be super nice that some of us who are interested in keeping it alive will have full control.

I did already patch my install and is almost 100% working on PHP 7just minor fixes found.

I will not update my entire platform which we spent thousands of hours to build right now at all. I do not have unlimited resources and I do not want to. Doesn't make any sense business oriented. It works perfectly until now. And I am sure many others have the same as me.

[shadowhand]

@neo22s well then do it. Don't keep asking for my opinion on things because my answer will continue to the same: Kohana is dead, move on. I still work on Kohana projects every single day and bit by bit every little refactor gets us further way from being dependent on it.

[neo22s]

@shadowhand ok, thanks I do appreciate the honesty.

Where is the correct place to speak about handing over KO? I will like to get full control of forum domain etc.. well not only me but a set of people of your trust of course.

[enov]

Kindly note that, if there will be any handling over to the project, I might leave.

@shadowhand was kind enough to provide write access to the repos to the team, and things are very transparent including governing.

Thanks.

[shadowhand]

@enov @neo22s @acoulton further discussion on maintaining at kohana/kohana#84.

[neo22s]

@shadowhand thanks a lot! ;)

[rasrobin]

I'd like to say i've read all comments on this issue with a lot of interest. I don't have enough knowledge yet to help writing on Kohana, but i'd like to give some feedback. I think voting 1 is a good choice. Having people update in 3.3 and not being able to use PHP 5 anymore would be very strange at the least.

The hacks are nice and can be good solutions for people using 3.3. It would be awesome if the kohana site contained a page where the hacks are explained with some documentation with pro's and cons. I know for one, I would very much appreciate it. I'm sure more kohana users that want to use PHP 7 in the future will too. (A topic on the Kohana forum or a blog somewhere would do too, but harder to find for people)

In the end the best solution would be if there would be a PHP 7 compatible 3.4 release. I have not read anything about 3.4, so i don't know what features it holds or what changes are keeping it from being released. If you'd ask me, the most important feature for a future release of Kohana is PHP 7 support. If anything else is keeping 3.4 from being released can it be pushed to 3.5?.

[neo22s]

closed since we are talking about this here kohana/kohana#84