3 minute read
Over the weekend I ran into a problem that gave the “too many errors: 88% scanned” error in one of my Script Includes. I had to figure part of it out on my own and then lo and behold andrew.kincaid also answered it in the community yesterday.
When I presented at the inaugural ServiceNow Developer Meetup in Seattle, I did a demo of the Istanbul Script Debugger. I noted that in the application I am currently developing, almost all of the serious logic lives in Script Includes. This is driven in large part by the fact that I have a lot of asynchronous work happening in Inbound Email Actions, webhooks and other forms that I can’t debug directly. By building the logic in a Script Include I can call it directly from Scripts - Background by creating the input by hand and then calling my function. This lets me step through. My webhooks and email actions are the thinnest layer that only take the input and call the functionality in the Script Include. Because I have the pattern of logging the full input as the first line of any of these entry points, it is easy to replay a transaction in the debugger and figure out where it went wrong (or right!)
All good, right? That’s a successful development pattern and a best practice recommendation. Well…
I ran into the error in the title just like the poster in the community. I also had no idea what was happening when I saw it. Because my Script Includes are holding all my logic, they are getting longer and longer which means they are ever more likely to trigger this situation. I was not familiar with this message either and could see no reason for the error at the point where it was triggering. I ended up solving it by copying my full Script Includes into JSLint: The JavaScript Code Quality ToolB and seeing what it was complaining about. Many of the “errors” were innocuous things like using single quotes instead of double quotes. By fixing those one by one (or via bulk replace in the case of the quote characters) I removed enough errors to allow my Script Includes to edit, save and operate properly.
Had I known the solution that Andrew provided, I could have saved time two ways. By including
// jshint maxerr:100
as the first line I could have prevented it from erroring out in my code. By including
// jshint maxerr:1
I could have skipped the need to use the external tool as my own editor would have told me line by line what it was finding troublesome.
Both of these are worthwhile patterns. Although some of these are arbitrary (before this, I had no idea anything in the engine cared between single and double quotes) being able to reduce these errors makes for cleaner code in the long run. I am now paying more attention to these errors and altering how I originate code to reduce them. If you plan on building up larger libraries of code in single files, it makes a lot of sense. Thanks, Andrew!
Share this post
Twitter
Facebook
Reddit
LinkedIn
Email