Notes
This unit contains common errors that some functions return. Nore error information will be added to this unit with time.
Important General Errors
If you receive an error such as
"err XX : see docs" in your web browser, those are general loading errors (such as missing library, missing config file) and descriptions can be found
here.
Typical Error Situations
Pretend you have a program as follows:
begin
WebWrite('hello!');
WebTempateOut('somefile.tpl');
end.
If somefile.tpl is missing and you have warnings enabled in your config settings, you will see a message on your screen that the file was missing. In later versons of 1.6.x branch the WebTemplateOut function also provides you with a FILE_READ_ERR result. This gives you plenty of options for how to handle the problem.
Logical Functions
Some functions return a simple false or true, and others return empty string values, and others warn you in your web browser, and other functions may return additional information. The
API Guide defines the rules/specifics. The type of error that can occur will be noted in the documentation.
Other notes
In version 1.5 and 1.6.0.0 not a whole lot of
extremely specific errors and no debuglns were implemented. Mainly warning messages were sent to the browser if you had warnings on.
In versions 1.6.0.2 and above, more and more error handling and debuglns options for you are implemented.
The Importance of Audit Trails
Generally speaking, each core function in the utilities also has debugln capabilities too, meaning that any function can be debugged if you enable DEBUGLN_ON in version 1.6.1 and above. You must setup the debugln procedure variable from pwumain to point to your own custom debug procedure of your choice in order for debugln's to work. Debugln's report additional verbose information about your web program.
See debugln and error tips for more information.
It is especially important in web programming to have debugln abilities, because many web programs run unattended and invisible. Since web programs run remotely on some server far away (or even near), a debugln audit trail is an important option to have access to in emergency situations.
In 1.6.1 the programmer can literally audit a program so precisely that he will know exactly which function begin, exited early, or ended gracefully. If a function did not finish, the log file will state so and the error will be easier to find than if using a debugger.
The problem with web programs is they run remotely unattended by thousands of users worldwide, so remote debugging each and every single instance of web programs would seem impossible - but it is in fact possible with a database. One can write an SQL handler in the debugln procedure. Writing debugln's to a text file or to the screen is a simpler debugln method.
Look for more log file capabilities in future releases
In future releases, more debug text file logging will be implemented which can be turned on or off. A special debug version of the DLL (when using dynpwu) will be available, which can be used temporarily by pointing the program to the debug DLL in the config file. When done temporary debugging and the program is ready for release, one will be then able to switch back to the regular DLL.
Use compiler switch to find errors at certain lines
You can also turn the -gl option on in your FPC compiler and/or the appropriate debugging compiler switches which trace which line of code your error is on. It is recommended only to turn debugging off when you really need to, such as if debugging really slows down the website, or you are releasing a live version of the site where you do not wish the user to see any errors inside the website itself (log files would be better), or if your server cannot afford to create large log files that bloat up the hard drive.
Turning off debugging is usually a form of premature optimization since it can be very helpful at times.