D
dbeavon
Guest
>>You can always fine-grain the handling ... I really don't want to... I just want to step out of the mess, and show the underlying error message to the user (whether the error is related to a unique constraint error or something totally unrelated.) But I cannot easily escape this portion of the callstack without first micro-managing the data in the temp-table. Notice that "EntryProg" shouldn't have to know about (or care about) the specific work that is being done within "HelperProg". It just cares if it succeeded or failed. Another programmer who reads "EntryProg" will be scratching their heads about why there is a step to "delete tt". (Granted that emptying the entire temp-table wouldn't be a major improvement, but it wouldn't involve micro-managing records or making an assumption that the current/default buffer is important in some way.) Are there any methods on temp-table that might reset things so the error doesn't come back to bite us a second time? I tried the following without luck. TEMP-TABLE tt:EMPTY-TEMP-TABLE (). EMPTY TEMP-TABLE tt. TEMP-TABLE tt:CLEAR(). I had pretty high hopes for the last one but it didn't work either.
Continue reading...
Continue reading...