I have some php code in a class that uses inheritance and requires and during that loading process, the error handler is setup. This interferes with my phpUnit test as it captures the exceptions/errors that phpUnit needs to run my tests. This is a large project and I can't just go change stuff. I can add stuff, though.
I cannot change the existing error handler code and as such I am looking for a way to make phpUnit be able to prevent the error handlers being called. I thought about overriding the call to set_error_handler, but this as expected gives the "cannot redeclare" error.
Currently I manually edit setup portion of the error handler by commenting the set_error_handler function call, but it would be nice if I could make this automatic without changing the source code (only changing the test code).
Is my problem clearly enough described?
Is what I need possible without adding runtime modules or changing the source code, i.e. just change the unittest php file?
Using php 5.5.
Related
I try to open an extbase view in a different window.
For this I call the function
\typo3\sysext\extbase\Classes\Mvc\Controller\AbstractController->redirect().
But it fails, due to abstract class AbstractController implements ControllerInterface. It can not find ControllerInterface. It is in the folder, but the folder isn't included in the path get_include_path().
Is there any way to go arround this problem without changing the TYPO3 file?
On the surface this looks like a typical class loading issue, so I'll describe the pitfalls there in case someone comes searching for that type of error and finds this post.
If you installed TYPO3 via composer, make sure you load the composer autoload file from your external file. Composer paths do not appear in the PHP include paths, and you should never have to include any other file than the composer autoload file.
If you did not install via composer you will need to run your script in a TYPO3 context. Only then will class loading work.
That said: the fact that class loading is inactive indicates you are trying to use TYPO3 features completely outside TYPO3. It is no easy task to simply use TYPO3 classes outside of a TYPO3 context - especially not Extbase ones, and especially not controllers. There are so many dependencies on configuration, database and request handling. I would strongly discourage attempting to do this.
Even generating a link to a controller action involves calculating a request hash which in turn requires access to the TYPO3 configuration and database. So in all likelihood, what you are attempting is simply not possible - you need to do it from within a TYPO3 context.
I installed the last version (Oxygen) of Eclipse for PHP. But now there are lots of error annotations that I think they shouldn't be.
Almost all of them have to do with Exception:
throw new Exception('Exception message');
The annotation message in the popup hint is like so:
Exception cannot be resolved to a type
And the hint offers me some quick fixes, which are using the Exception class declared in libraries imported with Composer.
Why is that? As far as I know, Exception is still an internal PHP class (no need to import it). I know I should be using more specific Exception classes, but for now, Exception works for me. And it shouldn't be marked as an error in Eclipse. Prior versions didn't detect this as an error. Furthermore the application runs without any problem.
Is this a bug? Otherwise, how do I disable this type of error annotation?
EDIT:
Another annoying issue happening is that the code assistant is not displaying any php internal function. Only functions, classes and methods declared in my app or in imported libraries. For instance, if I type:
str
the code assistant displays classes from Doctrine, Geocoder, etc, and imported functions like "strip_quotes", but nothing about strstr, str_pad, strpos, etc
Did you forgot about namespaces and PSR-4?
throw new \Exception('Exception message');
So when you are using a class which must be autoloaded, you must declare it via use or call it with full path (with namespace).
If you don`t want to write correct code and this message is annoying you, then I'm pretty sure that you can turn off this message via Eclipse configuration.
I'm trying to build a specific error "stack" for my applications. I have a small module system in place, and I want to be able to add the error handlers from the module to the current error stack. However, there are some error handlers that I want to be checked before the module error handlers, but those need registered before the module error handlers, in case there is in error in the module's bootstrapping process.
The stack I'm going for looks like:
Logging Error handlers
Alert Error handlers (firing off emails to developers if necessary)
Module error handlers
Application error handlers
Default fallbacks
When the application starts, the logging, alert, and default fallbacks are placed on the stack immediately. I want to be able to stub the application error handlers in next, and then the module error handlers once the module is determined and loaded. As far as I can see, error handlers can only be placed on the top or bottom of the stack; not inserted in the middle.
Is there a way to insert into the error handler? If not, is there a way to register a different error handling class (one extended from the built-in one)?
In the interest of time, I managed to come up with a solution that works. It's not what I was really looking for, but I'll share it in case anyone else needs to do something like this.
My approach was to extend the Illuminate\Foundation\Application and override the registerExceptionProvider() method to register my own ExceptionServiceProvider. This provider extends from Illuminate\Exception\ExceptionServiceProvider and overrides the registerHandler() method. In there, I register my Handler in the same manner the original provider registers the default handler.
I added insert* versions of each of the error methods provided by the default Application and an insertError method to the Handler that does the actual insert into the error handler stack. Lastly, I altered the start.php file to create my Application instead of the default one.
As I mentioned, I don't really like this approach; I feel it's more heavy lifting that what should have to be done. It seems like Laravel should have a better way to extend the actual error handler, or at least an interface to order the error handlers being registered more precisely.
I got hold of a dip into CI from CI forums and websites, which I have working. Basically; I have a fully working system in CodeIgniter, I have run tests that show a standard PHP file on the same server can access the classes and libraries that I made available.
One of the other legacy systems runs on Zend, and throws an exception when it incudes the CodeIgniter files. I can't get past:
$BM =& load_class('Benchmark', 'core');
in the dip file, with a long error being thrown by Zend. It throws (among much other information):
exception 'Zend_Exception' with message 'At least one error occurred including "Benchmark.php"; see includeErrors property'
Pretty much everything I can find on the internet finds ways to use the libraries from CodeIgniter, but that's the reverse of what I'm looking for. If I comment out the Benchmark loading, then it fails on Hooks, which leads me to believe that Zend has usurped or overloaded the load_class() function with its own, and is causing problems that way.
Has anybody gotten them working before?
I can't directly answer the question, but I just stumbled over a bit of rotting code referencing an Exception's "includeErrors" property.
After some search, I can maybe give a bit of context to what you observed.
Behaviour exists in some versions of ZF1 , see http://framework.zend.com/issues/browse/ZF-2463
if Zend_Loader includes a file
and the mere act of including it results in some PHP error (very often that will be E_STRICT if for example some inherited method signature doesnt match, or maybe if file is not found),
then it will throw an exception and add a "includeErrors" property to it
I'm having a problem with FuelPHP failing to autoload classes. On my staging server (Ubuntu, PHP 5.3.10) it is unable to find custom classes in the fuel/app/classes directory, and it also can't run oil test (I get the error message sh: 1: phpunit: not found). Oddly, it works fine on my local development version (Windows, PHP 5.3.6).
I suspected it might have something to do with Composer, which I'm using for the first time on this project, but the problem is not fixed when I comment out the line require APPPATH.'vendor/autoload.php'; from bootstrap.php (the app still fails to load custom classes from fuel/app/classes)
I'm stumped: I've used FuelPHP on lots of projects and have never had any problems with the Autoloader. What's particularly puzzling is that the same code seems to work fine in one place and not in another. I'd be very grateful for any suggestions about how to fix this.
I realize this question was asked a long time ago, but I had the same problem, so for the benefit of anyone else with this problem, here is what worked for me:
create a new php file called oil.php in the app/config directory with the following code:
<?php
// Unit tests will get shell error 'phpunit: command not found' unless
// the path to php unit is specified.
return array (
'phpunit' => array (
'binary_path' => 'fuel/vendor/bin/phpunit',
),
);
I am using fuel 1.7.2. More information can be found here.
Although the above code fixed the specific PHPunit problems, I still had issues with Fuel and autoloaders not working. Fuel PHP does not follow psr-4 (many of the core fuel files have multiple class definitions in the same file), which can cause problems with certain autoloaders.