We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.
  1. Home
  2. General

Error management

Hi All,

I'm just starting with Phalcon (following the INVO tutorial) and even though I'm really interested and excited by the framework, I get really frustrated with the error management.

First of all, I'm really surprised to not have a simple config parameter to switch the framework between a developer/debugging and productions modes right out of the box. Sure, now I've spent quite some time on it, it seems simple: removing the try/catch, instanciate the Phalcon\Debug and listen for errors...

My point is: it should be there by default in the bootstrap, with a nice comment telling us to replace it by a try/catch when reaching production. Do you realize developers are the first ones using the framework, and way, way later comes the production optimizations? Why not making is easy for developers (me and many others ) so we don't have to struggle and waste so much time looking in the forum for it. On top of that you have a really nice debugger, it's such a shame to not promote it.

Now, the main purpose of this post... So I'm using the Invo tutorial, got the debugger activated, and I'm struggling with the first SQL query. When I try to log in (/session/start), I get redirected instantly to the show500 error page. So I've placed a few traces in the code, and everything stops right on the first query:

SessionController.php >> startAction() >> $user = Users::findFirst(array(...)) ~line 50 Problem is, once again and despite the debugger, I don't have any error reported to me.

So could someone tell me what are my options here ? Alternatively, how can I get a full, raw, unprocessed error message ? Thanks in advance for the help. Cheers

EDIT: if I manually connection to my database and run a select query, everything works fine, aka my db params are correct.



125.7k

The Phalcon debugger only captures exceptions, and it squashes all output - so regular error messages don't get shown unless you call exit() right after the line that causes the error. I too find that a pain in the butt.

I've recently started using Tracy, which gives me a nice output of actual error messages (warnings, fatal errors, etc). It was pretty easy to install and set up.



24.8k
edited Feb '15

Thanks for the reply.

I'm happy to see I'm not alone struggling with the error management. I'm going to give a shot to tracy, not so much for "pretty" errors, but just to be able to see these.

I'm still wondering how people can build software on Phalcon if it is so difficult to debug and develop. I'm pretty sure there are complex mechanisms behind the scene, but a debug mode, even to simply spit raw errors into the page, seems fundamental to me.

Cheers



125.7k

I've not done this, but one common approach (for PHP development in general, not just Phalcon) is to have the errors logged to a file, rather than output on the screen. PHP can be set up to do this automatically - you may even be able to set the INI values in run-time.



24.8k

For a production / pre-prod environemnt I agree with you. But in a dev environment, and especially when trying a new and unusual framework, I want all the errors to pop in my face right away to know what I've done wrong and where to look.

Anyway, I've tried Tracy, and that's a great tool. Version 2.3+ (RC3 at the moment) implements an handy "shutdownHandler" that let's you catch all (or most of) the errors. Problem is, it doesn't provide proper backtraces when an error is fired inside Phalcon module (due to a bad usage/config, not a Phalcon bug).

As a result, I often end up with an error reported in index.php >> "echo $application->handle()->getContent();" when it comes from somewhere totally different. Examples: config error (path or value incorrect in config file), error in a view (block name containing "-" for example) ... report error in index file :/

The only solution I see it to implement both... or a mix of these, but it seems seriously tricky.



2.6k

I think I got here a little bit late, but I have the solution.

As you point out, there are several aproches to accomplish this, but I found that this kind of errors are visible if you place this lines of code at start of your file index.php on the public folder:

ini_set('display_errors', 1); ini_set('display_startup_errors', 1);

On top of one related piece of code that is already there: error_reporting(E_ALL);

If you encounter any other troubles, you can try placing this: display_errors = on

In the corresponding php.ini file, or modify the value if this setting is already active.

I hope this helps someone in the future!