42.8. Error Handling in PL/Tcl
Tcl code within or called from a PL/Tcl function can raise an error, either by executing some invalid operation or by generating an error using the Tclerror command or PL/Tcl'selog command. Such errors can be caught within Tcl using the Tclcatch command. If they are not caught but are allowed to propagate out to the top level of execution of the PL/Tcl function, they turn into database errors.
Conversely, database errors that occur within PL/Tcl'sspi_exec,spi_prepare, andspi_execp commands are reported as Tcl errors, so they are catchable by Tcl'scatch command. Again, if they propagate out to the top level without being caught, they turn back into database errors.
Tcl provides anerrorCode variable that can represent additional information about an error in a form that is easy for Tcl programs to interpret. The contents are in Tcl list format, and the first word identifies the subsystem or library reporting the error; beyond that the contents are left to the individual subsystem or library. For database errors reported by PL/Tcl commands, the first word isPOSTGRES, the second word is the Postgres version number, and additional words are field name/value pairs providing detailed information about the error. FieldsSQLSTATE,condition, andmessage are always supplied (the first two represent the error code and condition name as shown inAppendix A). Fields that may be present includedetail,hint,context,schema,table,column,datatype,constraint,statement,cursor_position,filename,lineno, andfuncname.
A convenient way to work with PL/Tcl'serrorCode information is to load it into an array, so that the field names become array subscripts. Code for doing that might look like
if {[catch { spi_exec $sql_command }]} { if {[lindex $::errorCode 0] == "POSTGRES"} { array set errorArray $::errorCode if {$errorArray(condition) == "undefined_table"} { # deal with missing table } else { # deal with some other type of SQL error } }} (The double colons explicitly specify thaterrorCode is a global variable.)