Hi,
I implemented try/catch in a few places.
But I do not see code landing there.
Instead, I see run time errors.
The pop-up window that shows the details disappears quickly and WL8 shuts off.
It seems WL8 grabs the system exceptions and does not pass them on to C# code.
a) It would be nice if the pop-up window stayed on until the user closes it.
b) It would be nice if code entered the catch part.
I write debug messages to a file to see what goes on.
Thanks!
I implemented try/catch in a few places.
But I do not see code landing there.
Instead, I see run time errors.
The pop-up window that shows the details disappears quickly and WL8 shuts off.
It seems WL8 grabs the system exceptions and does not pass them on to C# code.
a) It would be nice if the pop-up window stayed on until the user closes it.
b) It would be nice if code entered the catch part.
I write debug messages to a file to see what goes on.
Thanks!
Rename
I'm not so sure Try/Catch works in the main strategy code. I keep my main strategy code short and sweet (150-300 high-level lines) and use the WriteToDebugLog call whenever I encounter a high-level debugging problem.
However, I use Try/Catch extensively in my VS library code and it works beautifully even in a nested procedural design. Although my library code rarely changes, it does occasionally encounter "unexpected" data-dependent problems, and those errors need to be handled and logged. At the end of every catch{block}, I include an AddLogItem call so all the relevant parameters (such as bars.Symbol) for reproducing the error are included in the WL error log for later debugging. And I like how AddLogItem lets one color code hard (red; fatal), soft (yellow; recoverable), and informational (green) error types.
However, I use Try/Catch extensively in my VS library code and it works beautifully even in a nested procedural design. Although my library code rarely changes, it does occasionally encounter "unexpected" data-dependent problems, and those errors need to be handled and logged. At the end of every catch{block}, I include an AddLogItem call so all the relevant parameters (such as bars.Symbol) for reproducing the error are included in the WL error log for later debugging. And I like how AddLogItem lets one color code hard (red; fatal), soft (yellow; recoverable), and informational (green) error types.
Your Response
Post
Edit Post
Login is required