GMSoapUI
11 years agoContributor
[Res] Is there a smarter way of back tracing script errors?
Hi,
I have noticed this many times in the past while using SoapUI Pro and wondered if there is a smarter way to troubleshoot the problem.
Occasionally when I've amended some existing Groovy script or added new parts and run it through the first execution cycle and error appears in the Script Log pane and takes the format:
[ERROR MESSAGE] in Script [X].
Where [ERROR MESSAGE] is the particular text of the error and [X] is the number of the script where the error was encountered.
My question is, when there are a lot of scripts the error message, for example, "No such property delay in Script 16" is not very helpful unless I know what script Script 16 refers to. Why doesn't it actually use the friendly name of the script (i.e. the name I have called the Groovy script - "No such property delay in Script Driver" for example) to aid me debugging the problem rather than using an internal reference that takes an inordinate amount of time to track down? I have had to resort to keeping a separate note of which script number refers to which script, which is very protracted for something that should be very simple to implement.
Is there an easier way for me to determine what Script [X] is? The Error Log only shows me the exact same message and so is no further help.
Thanks.
I have noticed this many times in the past while using SoapUI Pro and wondered if there is a smarter way to troubleshoot the problem.
Occasionally when I've amended some existing Groovy script or added new parts and run it through the first execution cycle and error appears in the Script Log pane and takes the format:
[ERROR MESSAGE] in Script [X].
Where [ERROR MESSAGE] is the particular text of the error and [X] is the number of the script where the error was encountered.
My question is, when there are a lot of scripts the error message, for example, "No such property delay in Script 16" is not very helpful unless I know what script Script 16 refers to. Why doesn't it actually use the friendly name of the script (i.e. the name I have called the Groovy script - "No such property delay in Script Driver" for example) to aid me debugging the problem rather than using an internal reference that takes an inordinate amount of time to track down? I have had to resort to keeping a separate note of which script number refers to which script, which is very protracted for something that should be very simple to implement.
Is there an easier way for me to determine what Script [X] is? The Error Log only shows me the exact same message and so is no further help.
Thanks.