Yii Framework Forum: Error handling - Yii Framework Forum

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Error handling

#1 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,148
  • Joined: 17-January 09
  • Location:Russia

Posted 11 August 2011 - 05:08 PM

Currently Yii have a very useful error screen when debug mode is enabled: it shows stack trace and some code snippets where error is possible.

What are you missing at Yii error screen? How can we improve error handling?


Personally I'd like to add PHP fatal errors handling. In Yii 1.1 it can be done the following way:

class MyWebApplication extends CWebApplication
{
     public function __construct($config=null)
     {
         parent::__construct($config);
         register_shutdown_function(array($this, 'shutdown'));
     }

     public function shutdown()
     {
         if (YII_ENABLE_ERROR_HANDLER && ($error = error_get_last())) {
             $this->handleError($error['type'], $error['message'], $error['file'], $error['line']);
             die();
         }
     }
}


btw., maybe worth adding in 1.1.
Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
1

#2 User is offline   Maurizio Domba Cerin 

  • Yii - Yesss It Is !!!
  • Yii
  • Group: Yii Dev Team
  • Posts: 4,317
  • Joined: 12-October 09
  • Location:Croatia

Posted 12 August 2011 - 01:17 AM

The error screen is very informative and useful... only problem users can have is when they want to post the stack trace to the forum to request help...

the old error screen had a nice stack trace that could be copy/pasted and posted in the forum post

maybe to add the old stack trace on the end of the new error screen so that users can still just copy/paste it for posting...

IMO the fatal errors should happen only during development and I'm not sure if we can display more info than the standard error text... so the idea to handle it would be just to display it in a current layout... but again... those errors should happen only while developing not during production... so I'm not sure for this...
Find more about me.... btw. Do you know your WAN IP?
1

#3 User is offline   Mike 

  • Elite Member
  • PipPipPipPipPip
  • Yii
  • Group: Members
  • Posts: 3,013
  • Joined: 06-October 08
  • Location:Upper Palatinate

Posted 12 August 2011 - 01:50 AM

I like mdomba's idea to add a simple to copy&paste stack trace. I sometimes have to do remote debugging, too and non-techies have to send a screenshot now, to let me see the stack trace.

Another solution might be a small link on top like "Open text version in new window", to make it very easy to select the raw text of the stack trace.
0

#4 User is offline   Dana 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 203
  • Joined: 18-February 10
  • Location:Florida, USA

Posted 12 August 2011 - 06:37 AM

I like Mike's suggestion of 'open text version' -- seems like that would allow us to have the nicely displayed version as well as the copy/paste ability that some are lacking.
0

#5 User is offline   mindplay 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 397
  • Joined: 03-September 09
  • Location:New York

Posted 12 August 2011 - 08:37 AM

With web apps becoming increasingly dynamic, I would like to see a debugger that integrates with the client-side - using HTTP headers to transport log/trace information rather than HTML.
0

#6 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,148
  • Joined: 17-January 09
  • Location:Russia

Posted 12 August 2011 - 09:46 AM

mindplay
Can you elaborate about features of this debugger?
Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
0

#7 User is offline   mindplay 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 397
  • Joined: 03-September 09
  • Location:New York

Posted 12 August 2011 - 08:38 PM

Hmm, I think maybe I was getting the logging feature mixed up with the error-handler.

The error-handler doesn't pass it's output through the logging mechanism, does it? (why not?)
0

#8 User is offline   grigori 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 41
  • Joined: 06-February 11

Posted 15 August 2011 - 09:52 PM

The solution for AJAX debugging can be found in Django - you have the log in your console, rather then in a browser page.
With PHP 5.4 standalone web server support this can be implemented in PHP.
0

#9 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,148
  • Joined: 17-January 09
  • Location:Russia

Posted 17 August 2011 - 05:19 PM

Another idea is to convert all errors/warnings/notices into exceptions by default.

Why it's useful?

mkdir($dir);


The code above can raise warning if it can't create directory. Of course there are is_dir, is_writable etc. but it's hard to check for all possible conditions that could lead to an error. Moreover, checking with separate functions isn't atomic. So if project is under high load there can be a problem:

if(!is_dir($dir)){ // passes, there's no such dir yet
  // another process / thread creates directory
  mkdir($dir); // getting an error
}
else {
  // handle error
}


With exceptions it's atomic:

try {
  mkdir($dir);
}
catch(PhpError $e)
{
  // handle error
}

Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
1

#10 User is offline   jacmoe 

  • Elite Member
  • Yii
  • Group: Moderators
  • Posts: 2,601
  • Joined: 10-October 10
  • Location:Denmark

Posted 17 August 2011 - 07:31 PM

Exceptions:
I'd very much like it if you used them. :)
Would be great to have an option of turning them off, but IMO exceptions really beats having to deal with various error handlers - it's just feels too procedural.. Exception handling is the way to go. ;)
"Less noise - more signal"
0

#11 User is offline   Dana 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 203
  • Joined: 18-February 10
  • Location:Florida, USA

Posted 18 August 2011 - 06:35 AM

I agree with Jacmoe, I would prefer use exception handling where possible.
0

#12 User is offline   grigori 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 41
  • Joined: 06-February 11

Posted 21 August 2011 - 03:09 PM

> checking with separate functions isn't atomic

This looks like a pretty bad solution for a concurrency task in high load, you know that :)
I would say this is a sample of a bad code.

Converting errors to exceptions adds one general value:
you can place exception processing code where you want, rather then sticking to the error handler function.

The cost is increased complexity - execution may jump through multiple includes and hell knows where an exception gets caught and how processed in a team-developed application. We heard about this from Java world.
0

#13 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,148
  • Joined: 17-January 09
  • Location:Russia

Posted 22 August 2011 - 08:33 AM

Well, I can say that in Java it's pretty convenient to work with exceptions.
Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
0

#14 User is offline   mindplay 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 397
  • Joined: 03-September 09
  • Location:New York

Posted 02 September 2011 - 08:48 AM

View Postsamdark, on 17 August 2011 - 05:19 PM, said:

Another idea is to convert all errors/warnings/notices into exceptions by default.


I've seen this done with an error-handler before, it's quite useful - particularly because exceptions come with a stack trace, which makes for more useful error messages.

Code that produces E_WARNING tends to be poorly written, so I would agree that throwing exceptions for trapped errors/warnings is a good approach. E_STRICT could also be thrown, as it's usually an indication that you're writing code for an older version of the PHP language.

Notices on the other hand are sometimes just helpful information for the developer - I would not suggest you throw those, but rather I would prefer an option that allows me to pass those to a Logger.

One big issue with handling errors in this way, is the fact that legacy code and third-party libraries frequently produce E_WARNING - short of hacking vendor-supplied libraries, there wouldn't be much you can do to work around that fact. Unless we have an option to disable throwing for specific classes.

Another thing that custom error-handlers of this type frequently get wrong, is the error-suppression operator - if implemented, this must be supported and work as expected, as it's an integral part of the language.

It seems like there are so many ways to do this, it's tempting to make this error-handler highly configurable - but that would be both good and bad, since you would have to "learn", on every project you work on, how errors are handled for that specific project, and potentially you'll end up with modules/components that require a particular error-handling configuration, which could cause trouble when attempting to integrate modules/components into an application.

Also keep in mind the risk and learning-curve involved when changing standard PHP behavior. That's not necessarily a deterrent, when you're changing things for the better, but it does require a level of awareness or will to learn about differing conditions as compared to vanilla PHP code and/or other frameworks...
0

#15 User is offline   mindplay 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 397
  • Joined: 03-September 09
  • Location:New York

Posted 02 September 2011 - 08:52 AM

View Postgrigori, on 21 August 2011 - 03:09 PM, said:

The cost is increased complexity - execution may jump through multiple includes and hell knows where an exception gets caught and how processed in a team-developed application. We heard about this from Java world.


I deal with that pain every day in .NET - even in some of the core MS runtimes and official MS-supported libraries.

That said, I prefer this over "silent errors" - warnings/notices may go unnoticed, but an exception you have to deal with. You're forced to demonstrate in your code that you understand that an edge-case may occur. It's not a bad thing, necessarily - but does happen too often in .NET, and probably (from what I've heard) in Java, too...
0

#16 User is offline   Rodrigo Coelho 

  • Master Member
  • PipPipPipPip
  • Yii
  • Group: Members
  • Posts: 664
  • Joined: 05-August 10
  • Location:Rio de Janeiro, Brazil

Posted 02 September 2011 - 03:11 PM

View Postsamdark, on 17 August 2011 - 05:19 PM, said:

Another idea is to convert all errors/warnings/notices into exceptions by default.


Sounds good. And there could be some configuration options to include/exclude error levels (warning, notice, strict etc), just like PHP's error_reporting.

View Postmindplay, on 02 September 2011 - 08:48 AM, said:

One big issue with handling errors in this way, is the fact that legacy code and third-party libraries frequently produce E_WARNING - short of hacking vendor-supplied libraries, there wouldn't be much you can do to work around that fact. Unless we have an option to disable throwing for specific classes.


Yes, a way to work around this is to optionally filter by namespace or class. This way you can choose where to convert to an exception and where not to.
0

#17 User is offline   mindplay 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 397
  • Joined: 03-September 09
  • Location:New York

Posted 20 September 2011 - 08:17 PM

View Postmentel, on 02 September 2011 - 03:11 PM, said:

Yes, a way to work around this is to optionally filter by namespace or class. This way you can choose where to convert to an exception and where not to.


Good idea - I would suggest default behavior as follows: throw for undefined namespaces, but for the global (root) namespace, do not throw by default, since code that doesn't use namespaces is likely legacy code. All recent codebases/projects (worthy of mention) seem to use namespaces now.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users