D
dbeavon
Guest
@ske >> I don't understand, though, why you would not like to handle the error (delete the record) already inside the called program where the error occurred. Doing it any other way breaks the separation of concerns between the programs, as you mentioned. I would take that as a good reason for handling it there. And afterwards you can rethrow the error, if you still want to signal the caller about it too or go on to some more general error handling. Isn't that what rethrowing errors is good for? You are right that if I had to micromanage things, then I should do it in a program that is creating the TT record in the first place. (IE the micromanagement should probably be done by a catch block within the "DO v_Loop" of the HelperProg which is contextually the part of the code that "knows best" about that particular TT record!). However, I don't want to micromanage anything, or treat one type of error differently than another. For that matter, creating new TT records might cause the files in the SESSION:TEMP-DIRECTORY to grow too big and cause the unlikely overrunning of the free space of the disk. Should I be specifically checking for that particular type of an error too - while I'm at it? Sorry to be extreme but you get the idea. I only want to CATCH business-logic-related errors and let the technical cruft take care of itself (or get handled as generically as possible with a simple user message). What I am really after is some sort of a "generalized" convention or rule whereby I will start remembering to empty all the static TT/DS data in all of my CATCH blocks, especially when they are no longer relevant in light of the error. @Brian Based on the KB ( knowledgebase.progress.com/.../P43686 ) that fix appears to be related to entirely duplicate indexes. I don't think it is related to duplicate records in a single unique index.
Continue reading...
Continue reading...