Only when the custom assembly is compiled in "debug mode" (right-click in script editor), and an exception occurs, in addition to putting the Exception message into the Log tab of Control Center (which is what currently happens), it should output a stack trace (which because we're in debug mode has line numbers available) to the Log tab and/or to the Output window.
Additionally, there should be a setting somewhere such as in Tools -> Options for the maximum number of exceptions to log, such as one per run of an indicator/strategy/ninjascript, and another checkbox for whether to allow it to continue running or terminate it if the number is exceeded. These would default to the current behavior.
Yes, we can add the code to do this ourselves (and I often do if I'm tracking something down) but then again, why shouldn't "debug mode" do this for us? It's such a common need - and I can't count the number of times I've read a post in which support directs a beginning programmer to fill up their code with print statements to track down where something is failing - if they had this easy-to-add request, it would be quite clear - compile it in debug mode, and the Log tab will tell you the exact line number that threw the exception.
This is not only helpful to trader-developers in that it saves them time but it would also lighten the load on support. I'll bet they would use it as well so they don't have to keep doing what I do (adding the try-catch output re-throw etc. every time there is an issue or in anticipation of one). There are some threads like https://forum.ninjatrader.com/forum/...rmation-in-log in which this type of busywork is discussed - but it is the suggestion here that the platform should have this built-in, in the interest of doing the right thing and saving support and everyone using the platform time by pointing out exactly what the problem is.
Let's face it - if they're in "debug" mode, they already know they have a problem which many times is in the form of an unwanted exception - so knowing this, you should immediately give them the information they need to pinpoint it. You're already catching the exception because you're printing the message to Control Center. Just give them the full stack trace, and a way to limit how many of these it does, and they'll have what they need to make rapid progress.
Additionally, there should be a setting somewhere such as in Tools -> Options for the maximum number of exceptions to log, such as one per run of an indicator/strategy/ninjascript, and another checkbox for whether to allow it to continue running or terminate it if the number is exceeded. These would default to the current behavior.
Yes, we can add the code to do this ourselves (and I often do if I'm tracking something down) but then again, why shouldn't "debug mode" do this for us? It's such a common need - and I can't count the number of times I've read a post in which support directs a beginning programmer to fill up their code with print statements to track down where something is failing - if they had this easy-to-add request, it would be quite clear - compile it in debug mode, and the Log tab will tell you the exact line number that threw the exception.
This is not only helpful to trader-developers in that it saves them time but it would also lighten the load on support. I'll bet they would use it as well so they don't have to keep doing what I do (adding the try-catch output re-throw etc. every time there is an issue or in anticipation of one). There are some threads like https://forum.ninjatrader.com/forum/...rmation-in-log in which this type of busywork is discussed - but it is the suggestion here that the platform should have this built-in, in the interest of doing the right thing and saving support and everyone using the platform time by pointing out exactly what the problem is.
Let's face it - if they're in "debug" mode, they already know they have a problem which many times is in the form of an unwanted exception - so knowing this, you should immediately give them the information they need to pinpoint it. You're already catching the exception because you're printing the message to Control Center. Just give them the full stack trace, and a way to limit how many of these it does, and they'll have what they need to make rapid progress.
Comment