In debugging problems when using wwDotnetBridge, we'd often encountered strange behavior that turned out to be due to errors that occurred earlier in the program. This was caused by the way wwDotnetBridge object creation and invocation handled failure by setting Error. Even once we discovered the error-related properties, there's no easy way to be notified when they get set. To alleviate this, I added a function EnableThrowOnError to wwDotNetBridge in #12.
Before discovering wwDotnetBridge, in our own COM helper classes, we avoided catching exceptions and just let them propagate out to FoxPro. The crazy way errors would pop up was of course obnoxious, but at least we knew about them right away. :-) We hadn't run into any cases where an exception got in the way.
In debugging problems when using wwDotnetBridge, we'd often encountered strange behavior that turned out to be due to errors that occurred earlier in the program. This was caused by the way wwDotnetBridge object creation and invocation handled failure by setting
Error. Even once we discovered the error-related properties, there's no easy way to be notified when they get set. To alleviate this, I added a functionEnableThrowOnErrorto wwDotNetBridge in #12.Before discovering wwDotnetBridge, in our own COM helper classes, we avoided catching exceptions and just let them propagate out to FoxPro. The crazy way errors would pop up was of course obnoxious, but at least we knew about them right away. :-) We hadn't run into any cases where an exception got in the way.