Catch within a .w 10.2b

[jmac13]

In a gui Interface can you put a catch statement around the whole thing so that if there is a error with in the program you can deal with it?

e.g. if was a .p I’d just do a massive catch block around the code but how can I do this in a .w when I’m running lots of procedures etc?

Thanks

 

[mjpowellesq]

???
I think this is what U require.

ON ERROR DO:
/* cath error here */
END.

 

[TomBascom]

Unlikely. He's asking about the new 10.2 throw/catch error handling.

Something like:

/* badexample.p
 */

/* put this at the top
 */

routine-level on error undo, throw.

/* do stuff that might throw an error
 */


/* put this at the end of your program
 */

catch caughtErr as Progress.Lang.Error:

  define variable errNum as integer no-undo.
  
  do errNum = 1 to caughtErr:NumMessages:
    message substitute( "Error (&1): &2", caughtErr:getMessageNum( errNum ), caughtErr:getMessage( errNum )) view-as alert-box. 
  end.

  message "Catch: " caughtErr:Severity caughtErr:NumMessages caughtErr:CallStack view-as alert-box.
  undo, throw caughtErr.

end catch.

 

[jmac13]

Cheers tom

will this work in a .w? as im trying to deal with my errors in gui stuff the reason i ask is i want to turn the session:debug-alert flag on when its a error so the user can get at the stack trace then turn it off again. As i dont want the help button on normal messages as it looks naff


Thanks

 

[RealHeavyDude]

I've done it ( using the structured error handling in GUI code ). Out of experience I don't see any reason why it wouldn't work for you too.

Heavy Regards, RealHeavyDude.

 

[jmac13]

cool sounds good

When you say "using the structured error handling in GUI code" what do you mean? is it a matter of using what toms give me? and putting that in the main block.. cause just trying to work out how it picks up an error within the whole .w rather than having to put a try and catch in every procedure you doProcedure

 

[RealHeavyDude]

The code Tom gave you is a starting point. Unfortunately nothing is perfect and if you are not familiar with the "new" structured error handling ( that's how Progress calls this feature ) you might experience behavior that is not so obvious. But out of my experience this is more relevant for business logic procedure when it comes to transaction and buffer scope ( when do database triggers fire? ) - and your UI code should not change the database anyway. As always you need to understand the concept in order to successfully adopt it as well as the fact that you should be familiar with buffer and transaction scope.

Heavy Regards, RealHeavyDude.

 

[jmac13]

ok RHD,

I'll give it a go though not so bothered by transactions at this stage..plus we don’t have any triggers so that not a concern. Just want to see if we can deal with errors by getting the stack trace used in error reporting. Or anything really better than just a screenshot that we have at the moment

Cheers jmac13

 

[jmac13]

I just realised that if i throw the error then the stack trace isnt going to help anyway cause it will give me the trace of where the catch message is not the error its self....back to the drawing board

 

[Stefan]

If your only goal is to get a stack trace for real errors, then you could consider turning your thinking around and have session:debug-alert on by default and explicitly turn it off before a normal message.

 

[jmac13]

thats a very good point stefan...only problem with that is the tons of old code that doesnt have this in.. but yes moving forward thats not a bad idea at all...cheers plus i thought the error object can have info about the stack trace on it...

 

[Stefan]

Yes, you can use the :CallStack attribute on the error object, but you must enable error-stack-trace, which the manuals are full of 'beware effects performance' alerts.

ROUTINE-LEVEL ON ERROR UNDO, THROW.

DEFINE TEMP-TABLE tt FIELD cc AS CHAR.

SESSION:ERROR-STACK-TRACE = TRUE.

PROCEDURE foo:
   
   DO ON ERROR UNDO, LEAVE:
      FIND tt.
      CATCH e AS PROGRESS.lang.error:
         UNDO, THROW e.
      END CATCH.
   END.

END PROCEDURE.

DO ON ERROR UNDO, LEAVE:
   RUN foo.
   CATCH e AS PROGRESS.lang.ERROR:
      MESSAGE 
         e:CallStack
      VIEW-AS ALERT-BOX TITLE e:getMessage(1).
   END CATCH.
END.

 

[jmac13]

yeah i did see you have to turn it on... was going to turn it on within the catch then turn it off again... iam worried about the warnings though so I'll have to think about it. We've havent got any catch stuff at the minute so would be good to at least try and get some in to deal with errors better

 

[jmac13]

just realised i'd have to turn it on before the error...so that would cause an issue. So prob best sticking with ur idea turning in off for normal message and just having it on all the time.