Question
Royal Bank Of Canada (RBC Royal Bank)
CA
Last activity: 6 Nov 2018 20:02 EST
Robotics Automation-Logging
Hi there,
We are in the QA testing phase for our robotics solution and encountered a defect in our code. We looked into the logs generated and saw "Stack Trace" generated for the exception. So in order to do diagnostics and by looking at the Logs -Stack Trace, is there any way to identify from logs and trace at which place in the code the bug happened? I am attaching the log file (Stack Trace), if you can help in identifying a keyword in log which can trace/map to code as to which place in code I should be looking in to speed-up diagnostics v/s looking into entire code for the fix. Thanks for your help-Anupam
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Pegasystems Inc.
US
The lowest most exception is the one you are interested in. In this case the exception is a ControlNotCreated exception.
Exception Type: OpenSpan.Adapters.ControlNotCreatedException Message : The control Doclist is not matched.
In this case, the control is DocList. Somewhere in your automation you are attempting to use this control and it is not matched. Please see the post below for instructions on how to simplify your logs down to just showing the yellow and blue lines (and exceptions) in your solution. With these, you can walk backwards from the exception and locate which step you were on.
RBC
CA
I've run into the same challenge. As an example if I have intentional exception (divide by 0), the catch happens but there is not indication of where exactly the error happened. Unlike a C# application that gives an exact line of code that failed in the stack trace does not show a findable source of the error. the except is below: Attached is a pic of the automation script..
Any further details is appreciated..
<OpenSpanClipboard><row><col>Try..Catch.Exception</col><col>Exception Type: OpenSpan.Automation.PropagationException
Message : Unexpected error propagating data (NaN) between source (Automation1.numericExpression1.Evaluate().Result) and target (..Value).
Value was either too large or too small for an Int32.
Time Stamp : 2017/04/21 10:26:17 AM
Source : OpenSpan.Automation
Method : System.Object ConvertValue(System.Object)
Machine Name: 2736943W
Assembly Name: OpenSpan.Automation.PropagationException, OpenSpan.Automation, Version= Proprietary information hidden, Culture=neutral, PublicKeyToken=f5db91edc02d8c5e
Application Domain Name: OpenSpan.Runtime.exe
Thread Identity:
Windows Identity: MAPLE\776221434
I've run into the same challenge. As an example if I have intentional exception (divide by 0), the catch happens but there is not indication of where exactly the error happened. Unlike a C# application that gives an exact line of code that failed in the stack trace does not show a findable source of the error. the except is below: Attached is a pic of the automation script..
Any further details is appreciated..
<OpenSpanClipboard><row><col>Try..Catch.Exception</col><col>Exception Type: OpenSpan.Automation.PropagationException
Message : Unexpected error propagating data (NaN) between source (Automation1.numericExpression1.Evaluate().Result) and target (..Value).
Value was either too large or too small for an Int32.
Time Stamp : 2017/04/21 10:26:17 AM
Source : OpenSpan.Automation
Method : System.Object ConvertValue(System.Object)
Machine Name: 2736943W
Assembly Name: OpenSpan.Automation.PropagationException, OpenSpan.Automation, Version= Proprietary information hidden, Culture=neutral, PublicKeyToken=f5db91edc02d8c5e
Application Domain Name: OpenSpan.Runtime.exe
Thread Identity:
Windows Identity: MAPLE\776221434
Stack Trace:
at OpenSpan.Automation.PropertyLink.ConvertValue(Object sourceValue)
at OpenSpan.Automation.PropertyLink.PullValue(ExecutionEventArgs executionArgs)
at OpenSpan.Automation.ConnectableHost.PullData(ConnectableHost connectableHost, ExecutionEventArgs executionArgs, Boolean ifNoExecute)
at OpenSpan.Automation.ConnectableWorker.DoWork(Object sender, ExecutionEventArgs executionArgs)
Inner Exception Information
System.OverflowException: Value was either too large or too small for an Int32.
at System.Convert.ToInt32(Double value)
at System.Double.System.IConvertible.ToInt32(IFormatProvider provider)
at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider)
at System.ComponentModel.BaseNumberConverter.ConvertTo(ITypeDescriptorContext context, CultureInfo culture, Object value, Type destinationType)
at OpenSpan.Automation.PropertyLink.ConvertValue(Object sourceValue)</col><col>OpenSpan.Automation.PropagationException</col></row></OpenSpanClipboard>
Pegasystems Inc.
US
In your example rob, the Message portion of the exception on the second line tells you where it occurred. If you filter the logs as shown above, you'll be able to walk though all of the steps up to the exact point where the exception happens. Unlike C# there really is no line number that you could refer to in an automation that would translate to where on your automation to look. You'll need to do a little more investigation to locate the exact place, but if you filter the logs, they are usually pretty easy to pin down. Exceptions in a script will have line numbers, but those won't really relate to anything you can see (since each script is a method compiled into a larger object at run time). Those generally require adding logging messages (OpenSpan.Diagnostics.Diagnostic.TraceVerbose(category,message) )into the script to troubleshoot.
Pegasystems Inc.
US
You should identify the Thread ID that the exception occurred on. This will be in the first line of the exception block. From that point in the log, search upwards for the first line with ExecutionLink that occurred on that Thread. In most cases this will be the line that caused the exception.
If you add Try..Catch around an entire automation you may see an exception block for each automation below where the exception is bubbling up. The principal is still the same - find the first occurrence of the exception and then look for the ExecutionLink on the same thread that just occurred.