L
Laura Stern
Guest
Re Henri's post: Re the call stack and performance: If you need the call stack information just turn the feature on and don't worry about it. You are correct, that this only affects performance when an error occurs, not on every statement. And you're correct that probably you would never notice this performance hit in the schema of all the other stuff that is going on. Perhaps we were being overly cautious, but sometimes we get bitten when we aren't! Re your original request about having the error object available on ERROR-STATUS: I think I got it now. I believe you want this so that new code that uses CATCH/THROW inter-operates well with legacy code that uses NO-ERROR. But just so I'm totally clear on your use-case, let's be explicit. Seems like there are 2 cases: 1. If someone does a THROW using new structured error handling, the legacy code that handles it with NO-ERROR can then access the call stack from the original thrown error object. However, this implies that you'd change all the legacy code to check for this. I assume you could change your ReturnError.i to do this? 2. The legacy code that uses NO-ERROR can trap a Progress error and the error object would be available off of ERROR-STATUS. So again, how would you handle this in your ReturnError.i? Would you change this into a THROW of the object? Or would you just read the call stack out of the object and add it to your RETURN ERROR string, avoiding the need for you to put the call stack together yourself?
Continue reading...
Continue reading...