EasyDebug
Debugging is one of the most crucial parts of software development and one of the most hard things to do for newbie developers.
When it comes to CGI debugging, the problem gets bigger since we can't launch a debugger tool to inspect the application while it is in memory. Web developers, specially xTalkers, often keep reinventing the wheel. The most common things xTalkers do are writting to some log file or always reinventing the error report routines for each project. The trouble with log files is that you loose time by going to the server to check them, in the modern world of ubiquitous cable modens one might think a trip to the server thru ftp will do no harm, but just imagine going to the server dozen times in a single hour while you try to debug your application, not the most pleasant taksk. The idea of reinventing the error report tool for each project is also bad because you loose time doing that no matter how much code you reuse. To solve this problems we present the EasyDebug CGI library.
To get this library and others, download RevOnRockets.
What does it do?
It will present a HTML report is an error happens. This report will include a human readable message specified by the developer and/or by the engine. It will display your application source code and highlight in red the error lines, it will also use the execution context to help you localize where the error trapping routine was triggered. It will show you stacks in the message path and open and display the global values.
The EasyDebug works for any project, its unique dependency is EasyCGI Core Library. To use it you just put it in the message path with a 'start using' command, then you enclose your cgi in a try/catch block and pass the error statement of the block to the cgiError routine. Let me show you an example:
on startup
start using "EasyCGI.rev"
start using "easydebug.rev"
...
try
-- do lots of things that can result in errors...
catch theError
cgiError theError
end try
the cgiError routine will generate the report and present it in case some error occurs, you can also call this handler by hand outside a try catch block. You can even lock the error dialogs in your main handler and EasyDebug will trap the errordialog message for you.
To see how the report looks like, point your browser here this is a test cgi that tries to access a stack that doesn't exist. You'll see the source, the report, the error lines and the execution contexts that triggered the cgiError routine.
Feedback and changes
This library as all the EasyCGI ones is freeware with source. It is in its early stages, I coded it in maybe two or four hours and theres lots of places for organization and clean up. If you add or change the routines to a better use or you create a better template than mine, please send it back to me for merging with the main library. The improvements I'd like to add are all easy, I just don't have the time to code it now, the library in its current stage works for me and for most projects.
Places for improvement:
Better template.
Display just a snippet of source code, not all the source. EasyDebug tries to display the full source for the handler that where error happened. In the case it doesn't know in what handler it happened, it displays the full source. This depends on the try/catch block error statement, for some it contains handler information, for others just line numbers. With some more handling and RegEx, this display of data could be improved.
Colapsible parts. This should fall under better template, but its just that it might be productive wise to have some javascript routines to colapse and expand the source reports and the parts of the report.
Email sending. With the aid of EasySendmail the error report could be emailed to the main developer in the case of testing software with a beta test group.
No report option. Right now, the library reveals much of your intelectual property, for those that belives in shared fantasies such as patents, money and the stock market, this is a huge issue. Very soon an option to diplay just a default error with no info in it will be available and the actual report can be saved to a file and/or mailed to the developer. As it is, you should just remove the library from your deployed project.