Better error messages

The error messages that you get when something goes wrong in a production line are often not very helpful. A Java stack-trace seems more suited to developers debugging the product than to users testing an application -- which is why you want to include the log when emailing support. Fortunately it is fairly easy to make the messages more useful for you as well.

Put a script like this into the relevant Connector's Default On Error hook:

task.logmsg("****** Error *******");
task.logmsg("****** Work *******");

// May or may not want to do this:

The effect of this is to dump out the error object and the work object whenever an error occurs in the connector. The Java stack-trace will not be produced because the On Error hook is enabled.

If you also want to dump the conn and current objects (which may not be defined at the point of the error) you can wrap these in try-catch blocks:

try { 
  task.logmsg("****** CONN *******");
  task.dumpEntry( conn )
} catch (e) { // Do nothing }
try { 
  task.logmsg("****** CURRENT *******");
  task.dumpEntry( current )
} catch (e) { // Do nothing }

You will need to decide on a case-by-case basis whether to include the system.skipEntry() line. See the SkipEntry page for more information on this.

Note also that the logmsg() method optionally accepts a log-level parameter:

task.logmsg("This message is written at INFO level");
task.logmsg("WARN", "While this one is at WARN");
task.logmsg("FATAL", "And this is a FATAL message");

This allows you to control which Log Appenders get the message.

For more on how Errors are handled in TDI, check out the HowTo page.

-- AndrewFindlay - 01 Nov 2005

-- EddieHartman - 07 Nov 2005
Topic revision: r3 - 07 Nov 2005, EddieHartman - This page was cached on 04 Aug 2023 - 16:58.

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TDI Users? Send feedback