Error information regarding each function is currently kept in the API Guide. Each documentation page will try to explain in detail what happens if a function fails.
See also the following pages:
pwumain.debugln:= @YourDebugProc; // make a procedure to write to somewhere
webwrite('hello');
webtemplateout('badfile.tpl');
Debugln is meant for additional verbose auditing. Even with debugln() not set up, you will still see important errors and warnings on the screen and be able to detect typical errors with function results.
uses
pwumain;
procedure CustomDebug(s: string);
begin
// Write to a log file, or to a database here.
// If you write to a file, file sharing conflicts occur in a live environment
// Your web program will be slowed down if you write all debugging to a log file.
writeln(yourlogfile, s);
end;
begin
// set up your debug system which pwumain will use
pwumain.debugln:= @CustomDebug;
webwrite('web program');
GetCgiVar('test');
WebTemplateOut('badfile.tpl');
// Your log file will include hints such as
// Begin GetCgiVar
// End GetCgiVar
// Begin WebTemplateOut
// WebTemplateOut: Exit, could not find file: badfile.tpl
// If the function does not End or there is an error, then the log should tell you
// what Exit point was hit, why it was hit, and/or detailed info about why the
// function had an issue or a problem completing
end.
Assigning your own debugln procedure tells pwumain to send text to somewhere that you specify in your custom debug procedure. Each function in pwumain will write information on what function it recently entered and exited.
Example, in the future it will be something like:
uses pwuMain, pwuDebugMsg; procedure CustomDebug(msgcode: integer); var msgstr: string; begin // convert compact integer code to detailed message msgstr:= MsgToStr(msgcode); // write to verbose text errors writeln(yourlogfile, msgstr); // or save space and write just debug codes writeln(yourlogfile, msgcode); end;
Debugln's are for extremely verbose auditing of your web program.
On a web server (especially large scale applications), having an audit trail is more important than simply displaying a rude message to the end user such as
X3494553 Acceess Violation, creepy exception number 209874953, we are bad programmers and don't know what we are doing and now our customers hate us.We've tried to make every message polite instead of abrupt.
You will want to use DebugLn and send debug info to a database when you have problems with a program that you can't trace through other means. A database is better than a log file on a live server simply because a database can handle multiple writes at once (several people will be visiting your website, not just one person at a time). On localhost or smaller servers, you can simply chose to write debugln info to a log file or use file sharing functions.
Without using any debuglns, however, many functions return booleans, errors, and empty strings to signal a problem. Some serious issues are written as warning messages to the screen too.
Basically, you shouldn't need to use DebugLn. However, if you do need to audit your program extensively with ridiculously detailed information, then debugln is there for you. For example if a file does not exist, it makes sense to have a function result that tells you the file doesn't exist when you call the webtemplateout function, you can easily trap whether or not the program is finding the file by seeing a warning message on your screen and/or checking the function result. This file missing issue would be easy to track down without using any debugln calls.
However, if you have some bizarre issue which you cannot find a solution for, or if your customers are experiencing bizarre issues, then the debugln system would tell you much more verbose information: what point your program failed to find the file, what functions launched before and after this issue occurred. Debugln would also tell you if functions exited early or if they ended gracefully.