Feature request

Jack posted on Friday, February 06, 2009

It would be nice if some of the recursive functions that throw exceptions could either re-raise and throw the exception or include some basic information that would help a developer determine where it happened.

For example I was struggling with a CopyState / BeginEdit() issue and while I had an idea where it was happening my object graph was sufficiently convoluted that step debugging was horrendous.  I ended up modifying the exception thrown in FieldDataManager.CopyState to include the FieldName/loopIndex so I had somewhere to start.

Throw in remote proxies and debugging gets even tougher.

Thanks

jack

rsbaker0 replied on Friday, February 06, 2009

I don't disagree, but I've found that usually, if you are in the debugger, that if you cause the debugger to break at the time an exception is thrown (versus only on unhandled exceptions), you can usually see what field was being manipulated by looking back a few levels on the call stack. (at least in the case of the dreaded edit level mismatch exceptions, which usually occur client side)