Deluge is a powerful language that simplifies a ton of things, e.g. database lookups. But I have to say, it's very painful to debug. Interpreting longish scripts takes ages, error messages are obtuse if they exist at all and even the hints in the IDE don't always help (ever tried using containsIgnoreCase based on the auto-complete suggestion?).
Here are my tips for debugging code when it's not working.
1. Split your code up into small custom functions. Nothing's more painful than waiting 30 seconds for a really long (say 1000 lines) HTML page to save and only then get feedback on a syntax error. I've got a few apps that are like this and it's not fun to work with at all. I haven't seen any improvements in the compile speed over the last few years, so my conclusion is that it's always best to write most of your logic code as small custom functions and then build that up in the HTML page so that you'll get quick feedback on syntax errors.
2. If your code doesn't do what you expect it to do, use info statements to log out values along the way. E.g. if I expect a CRM searchRecords task to return certain data and then perform operations on it afterwards, it would be prudent to throw an info crmRecords; call in before so I can check that it's actually retrieving the correct records. Info statements are only shown to admin users but you should still probably remove them after you've finished debugging.
3. If all else fails, comment out blocks of code to identify what's causing the error. I find this helpful for catching syntax errors that the Deluge compiler rarely shows properly. I code in Javascript most of the time and so when I go to Deluge (which looks very similar to JS), the temptation is to write things like listRecords = new List(); (instead of listRecords = List();). This code will often throw some weird error message pointing at a line that is completely unrelated to where the error is or it sometimes doesn't even throw an error at all (particularly when you're writing custom functions in the CRM).
To identify the culprit, I find it easiest to comment out blocks of code until the whole thing compiles and then figure out which of the commented blocks caused the issue.
Here are my tips for debugging code when it's not working.
1. Split your code up into small custom functions. Nothing's more painful than waiting 30 seconds for a really long (say 1000 lines) HTML page to save and only then get feedback on a syntax error. I've got a few apps that are like this and it's not fun to work with at all. I haven't seen any improvements in the compile speed over the last few years, so my conclusion is that it's always best to write most of your logic code as small custom functions and then build that up in the HTML page so that you'll get quick feedback on syntax errors.
2. If your code doesn't do what you expect it to do, use info statements to log out values along the way. E.g. if I expect a CRM searchRecords task to return certain data and then perform operations on it afterwards, it would be prudent to throw an info crmRecords; call in before so I can check that it's actually retrieving the correct records. Info statements are only shown to admin users but you should still probably remove them after you've finished debugging.
3. If all else fails, comment out blocks of code to identify what's causing the error. I find this helpful for catching syntax errors that the Deluge compiler rarely shows properly. I code in Javascript most of the time and so when I go to Deluge (which looks very similar to JS), the temptation is to write things like listRecords = new List(); (instead of listRecords = List();). This code will often throw some weird error message pointing at a line that is completely unrelated to where the error is or it sometimes doesn't even throw an error at all (particularly when you're writing custom functions in the CRM).
To identify the culprit, I find it easiest to comment out blocks of code until the whole thing compiles and then figure out which of the commented blocks caused the issue.
Comments
Post a Comment