Error handling

[GoogleCodeExporter]

=== The situation ===

Currently, v8cgi simply shows a 500 page if there's any errors in the
javascript.

I noticed that if a try/catch is put around the code, you can catch all errors!

=== Resolution ===

I suggest that the through some mechanism, a try/catch is automatically
inserted around the main javascript file to be executed.  The catch block
would invoke a default onError() handler that would print a nice error
page.  If v8cgi is configured for "production" mode, the error page would
be something like the current 500 page (apache's).  If not, then the error
page could dump out the exception.

Note that code can throw two ways:

  * throw "some message";
  * throw new Error("some message");

*If the second is thrown, then a javascript stack trace is available to the
error handler!*

Thus, v8cgi source should be examined and the second type of exception
thrown anywhere an exception is currently thrown (may already be the case).

The application should be able to provide its own error handler.

Original issue reported on code.google.com by mykesx on 7 Sep 2009 at 8:54

[GoogleCodeExporter]

I implemented an errorHandler and put try/catch around a test page.  It does not
catch all compile errors - I think this is going to have to be handled in 
mod_v8 C++
code.  However, it does catch runtime errors and this is the resulting output:

500 Error
ReferenceError: foobar is not defined
     at yyy (/raid/home/mykes/www/v8/htdocs/index.sjs:11:1)
     at xxx (/raid/home/mykes/www/v8/htdocs/index.sjs:8:1)
     at /raid/home/mykes/www/v8/htdocs/index.sjs:6
Dump of Exception Object:

(object) :
 [message] : (string) foobar is not defined
 [stack] : (string) ReferenceError: foobar is not defined
    at yyy (/raid/home/mykes/www/v8/htdocs/index.sjs:11:1)
    at xxx (/raid/home/mykes/www/v8/htdocs/index.sjs:8:1)
    at /raid/home/mykes/www/v8/htdocs/index.sjs:6
 [type] : (string) not_defined
 [arguments] : (array) :
   [0] : (string) foobar
 [name] : (string) ReferenceError

Server Environment:

(object) :
 [HTTP_HOST] : (string) v8
 [HTTP_USER_AGENT] : (string) Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.13)
Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13
 [HTTP_ACCEPT] : (string) text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 [HTTP_ACCEPT_LANGUAGE] : (string) en-us,en;q=0.5
 [HTTP_ACCEPT_ENCODING] : (string) gzip,deflate
 [HTTP_ACCEPT_CHARSET] : (string) ISO-8859-1,utf-8;q=0.7,*;q=0.7
 [HTTP_KEEP_ALIVE] : (string) 300
 [HTTP_CONNECTION] : (string) keep-alive
 [HTTP_CACHE_CONTROL] : (string) max-age=0
 [PATH] : (string) /usr/local/bin:/usr/bin:/bin
 [SERVER_SIGNATURE] : (string) 
Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.2 with Suhosin-Patch mod_v8cgi Server 
at v8
Port 80

 [SERVER_SOFTWARE] : (string) Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.2 with
Suhosin-Patch mod_v8cgi
 [SERVER_NAME] : (string) v8
 [SERVER_ADDR] : (string) 127.0.0.1
 [SERVER_PORT] : (string) 80
 [REMOTE_ADDR] : (string) 127.0.0.1
 [DOCUMENT_ROOT] : (string) /home/mykes/www/v8/htdocs
 [SERVER_ADMIN] : (string) webmaster@localhost
 [SCRIPT_FILENAME] : (string) /home/mykes/www/v8/htdocs/index.sjs
 [REMOTE_PORT] : (string) 59388
 [GATEWAY_INTERFACE] : (string) CGI/1.1
 [SERVER_PROTOCOL] : (string) HTTP/1.1
 [REQUEST_METHOD] : (string) GET
 [QUERY_STRING] : (string) (empty)
 [REQUEST_URI] : (string) /
 [SCRIPT_NAME] : (string) /index.sjs

Original comment by mykesx on 7 Sep 2009 at 9:48

[GoogleCodeExporter]

How do you call the error event? 

I use

try {}
catch (error) {
    response.write('<dialog style="color:red">'+error+'</dialog>');
    response.write('JSON.stringify(error)');    
}

got only the message with some arguments. 

Original comment by bienmano...@googlemail.com on 4 Oct 2009 at 8:52

[GoogleCodeExporter]

Please see
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Er
ror
for more details:

try { 
  throw new Error("test", ..., ...);
} catch (e) {
  response.write(JSON.stringify(e));
}

Also, starting from rev.566, there is a configuration directive 
Config["showErrors"],
which determines, what should happen to uncaught exceptions.

Original comment by ondrej.zara on 13 Oct 2009 at 7:38

[GoogleCodeExporter]

Forgive me my lack of experiences with subversion. My question was bashful, 
because I
was something desperately of the missing of line numbers. Now I played with 
Mykesx
ErrorHandling-class from the example kit and found a good way how to get an 
useful
module-error:

var error = e.stack ? (e.stack).replace(/ at /g,'<br/>\n at ') : e;
write(error);

Maybe the stack-string - if available - should be the standard return. A better 
way
would be to have the stack as an json or array, witch handles some information 
about
the "linked" Object (like ZF do). The actual stack-as-message I've god looks 
like:

TypeError: Cannot read property 'events' of undefined
 at [object Object].
(/home/www/web0/html/labs/v8cgi/raccoon/vendor/raccoon/raccoon.jx:45:24)
 at [object Object].
(/home/www/web0/html/labs/v8cgi/raccoon/vendor/raccoon/Raccoon/Core/MooTools.jx:
876:22)
 at [object Object].
(/home/www/web0/html/labs/v8cgi/raccoon/vendor/raccoon/raccoon.jx:36:7)
 at [object Object].
(/home/www/web0/html/labs/v8cgi/raccoon/vendor/raccoon/Raccoon/Core/MooTools.jx:
876:22)
 at new
(/home/www/web0/html/labs/v8cgi/raccoon/vendor/raccoon/Raccoon/Core/MooTools.jx:
830:50)
 at /home/www/web0/html/labs/v8cgi/raccoon/app/index.jx:7:1

Original comment by bienmano...@googlemail.com on 22 Oct 2009 at 1:35

[GoogleCodeExporter]

By the way: JS is a language well prepared for working with exceptions and 
developers
are highly encouraged to do so. If your code contains places where failure is an
option, you _should_ wrap these into a try-catch code block. In catch 
statement, full
details regarding the exception are available to be printed / analyzed / 
whatever.
The Config.showErrors directive is only relevant for uncaught exceptions - 
something
that should _never_ (ideally) happen. These include syntax errors (relevant only
during the development process) and uncaught runtime errors. The latter should 
be
thought of and handled properly by the developer, not by the v8cgi itself.

Original comment by ondrej.zara on 22 Oct 2009 at 10:39

[GoogleCodeExporter]

Original comment by ondrej.zara on 10 Nov 2009 at 8:49

• Added labels: Priority-Medium
• Removed labels: Priority-Critical

[GoogleCodeExporter]

v8cgi now handles exceptions in a consistent manner.

Original comment by ondrej.zara on 9 Dec 2010 at 8:05

• Changed state: Fixed