The biggest problem I have seen with Tcl procs is that they do not address anomalies. People write procs as if they will never fail. You should play devil’s advocate and be able to catch any error, especially file or DB failures. Remember, as Murphy said, anything that can happen usually will happen. Once you catch the errors, how you handle them is up to you. You could write a message to the log file. If you do put a couple of linefeeds before and after the message so it stands out. You could send an email. You could shut down the thread. If you do that I would shut down the process since the process may be busy and not shut down the thread. You can do a combination of these. There is no one size fits all. What you should never do is to allow a failure to come down around your ears. Allow it to fail on your terms. It can be handled.
Totally agree. The preferred outcome is that if a proc fails for one reason or another, the message does not get sent and thread doesn’t stay up. We want it to change thread status to error/down, and queue the message back into it’s original state just before the error (1-11). This way, we’re able to see the error in the process log and perhaps write some TCL in the alert or proc to perform environment checking and proceed if all good.
Email: joshua.cooper@allscripts.com
————————————-
Allscripts
Mobile, AL
