Trapping stop AND errors

[schaapie]

I am trying to catch stop conditions (caused by a lock timeout) and errors in a program calling another program.
I have tried various options, but end up trapping either errors OR the stop:
Has anyone any clue how to do this?

Following code is some of the things I tried, but now I can't distingish between the type of errors occuring (.p not found, lock timeout, db-not connected, parameters incorrect etc.).

output to c:\temp\1.txt.
run runWithStopDetect('dwobj/TabelCategorie.p') no-error.
put unformatted 'error ' error-status:error skip
  'num ' error-status:num-messages skip
  'return ' return-value.
output close.
 
procedure runWithStopDetect:
  define input  parameter cScript as character   no-undo.
  do on error undo, leave
     on stop undo, return "Stop event":
    run value(cScript) no-error.
  end.
  put unformatted 'error'
      error-status:error
   error-status:num-messages skip.
end procedure.

 

[TomBascom]

What version of Progress?

It matters deeply -- there have been major enhancements made to error handling of late.

 

[schaapie]

OE 10.1c03

 

[GregTomkins]

I don't know if this helps, but:

1. If the failure is due to mismatched parameters, RUN NO-ERROR and then Looking at ERROR-STATUS:GET-MESSAGE() will tell you this.

2. If the failure is due to .P not found, in which case STOP occurs, you can do this (see below) to trap the error. However, there is, AFAIK, no way to suppress the error message caused by the RUN. In other words, 'NO-ERROR' is kind of a lie. This sucks, IMHO, though it's not a big deal - if a .P is missing, you're probably SOL anyway.

<code>
DO ON STOP UNDO,LEAVE:
RUN c:/xtemp/wtf.p NO-ERROR.
END.
MESSAGE "WTF " + ERROR-STATUS:GET-MESSAGE(1) VIEW-AS ALERT-BOX.
</code>

Editorial comment: so some programmer at PSC decided that a missing .P is a disaster, but mismatched parameters are a minor problem. IMHO these two problems should be considered equally serious, or, there should be some ability to configure how they are handled.

3. If the failure is due to the .P executes a STOP explicitly, the GET-MESSAGE will return blank, but ERROR will still be set.

4. I'm not sure what happens if the failure is due to a lock timeout; those happen so rarely in my world, I can't be bothered to invest the time to figure out how to recreate one quickly.

These comments apply to 9.1; I am aware that in 10.x there is a bunch of try-catch stuff, but I think the above description is still valid, but I wouldn't swear by it

 

[schaapie]

When I test, the stop caused by a lock-wait-timeout does NOT set error-status:error to true.
So I end up leaving the block with num-messages = 0 and error-status:error = no.

 

[KrisM]

These comments apply to 9.1; I am aware that in 10.x there is a bunch of try-catch stuff, but I think the above description is still valid, but I wouldn't swear by it

I have asked a question about this on the Exchange 2009.
Try-catch cannot be used on stop conditions.
Apparently this is exception handling and not error handling.