capturing progress error

S

shafee212

Member
How to capture error in progress , I mean if any progress error comes in any part of program execution , then how to capture it .
 
You're telling nothing about the Progress/OpenEdge version you are using.

As of OpenEdge 10.1c and onwards you might have a look at the structured error handling.

Otherwise you should have a look at something like this:

DO ON ERROR UNDO, LEAVE:

END.

or the NO-ERROR option on some ABL statements which will set the ERROR attribute on the ERROR-STATUS system handle.

Is there something in particular you have in mind?

Regards, RealHeavyDude.
 
Hello Everyone,

I have a related query, i don't know either i should add a new thread for this or should i use the related one.

No matter what type of ERROR progress generates, i want to override those errors with my own message. somewhere i saw similar code for this purpose:

Code: 
OUTPUT TO VALUE "filename.txt".
   FOR EACH customer WHERE balance > 10000:
   DISPLAY name.
   END.
OUTPUT CLOSE.

CATCH e progress.lang._____.
MESSAGE "____"
   VIEW-AS ALERT-BOX.

Is this the only way to override all progress generated error, If yes then do we need to learn all related progress libraries for that?

Please suggest.

Thanks & Regards!!
Rajat.
 
I don't have a specific suggestion but IMO this is one of the weakest areas of Progress. For example, the fact that a 'RUN x.p' where x.p does not exist is handled so differently than 'RUN x.p(y)' where x.p does not expect any parameters is pretty terrible. And don't get me started about all the inconsistencies and weirdnesses of ERROR-STATUS, NO-ERROR, etc.
 
I know a very smart guy who was demonized and nearly fired because of bugs that another programmer introduced by simply ignoring the existence of RETURN ERROR and its friends. All of his carefully crafted and really kind of elegant code was ruined by simple ignorance and sloth.
 
The error ( or exception ) handling, IMHO, is one the most omitted featuers of "cool" software of careless developers. No matter what technology you use you need to understand how errors ( exceptions ) are treated by the technology and whether standard behavior ( like the default error handling capabilities of ABL blocks ) kicks in. Actually it is sometimes pretty hard to produce code that holds water when it comes to error handling but most of the times, IMHO of course, it is sloppy developers.

How often have you been annoyed by those tale-telling Java stack traces?

For me the bad thing about the way errors are handled in the ABL is, that it makes it so damn easy to write code that eats errors. Just use the NO-ERROR option consistently throughout your code and most likely you will not bother your users with ABL error messages.

Having said that, I think the structured error handling that was introduced with OOABL is a really good thing. I even use it in procedural code.

But, yes, sice it is not like in Java where the development environment automatically enforces the handling of "declared" exceptions, if you want to transform every possible error message into your custom one, you need to know.

Did you know that Progress provides translated versions of the promsgs in the respective prolang sub directories that you can use out-of-the-box?

Heavy Regards, RealHeavyDude.
 
TomBascom said:
I know a very smart guy who was demonized and nearly fired because of bugs that another programmer introduced by simply ignoring the existence of RETURN ERROR and its friends. All of his carefully crafted and really kind of elegant code was ruined by simple ignorance and sloth.
Click to expand...

Was he called Tom?
 
Hello Everyone,

So, instead of suppressing the errors i should understand the problems causing errors and tackle them accordingly.

Hi Dude, i am not much aware of the promsgs in the respective prolang sub directories. Is there any documentation or something that i can go through for this?

Thanks & Regards!!
Rajat.
 
Rajat Sharma said:
So, instead of suppressing the errors i should understand the problems causing errors and tackle them accordingly.
Click to expand...

I think the point is not so much that you should not suppress exceptions; it is bad form (in my opinion) for end users to see unhandled exceptions from the runtime. Rather, 4GL/ABL developers need to understand that this is a mature language that has evolved over three decades where the prevailing industry best practices for language design, exception handling, and application design and architecture have changed quite dramatically.

The 4GL reflects this evolution in its mix of capabilities: procedural code, object-oriented code, client/server, web services, etc. etc. I think RHD's point is that many developers use keywords like NO-ERROR in their code without fully understanding the implications of their use, and without understanding in sufficient depth how the 4GL handles (or can be written to handle) exceptions.

Rajat Sharma said:
Hi Dude, i am not much aware of the promsgs in the respective prolang sub directories. Is there any documentation or something that i can go through for this?
Click to expand...

A good place to start would be the "Internationalizing Applications" manual in the OpenEdge documentation set. It discusses the localized promsgs files, parameter files, and many other topics related to localizing applications, should you need this.
 
Hi Rob,

I can understand your valuable inputs regarding progress errors.
Where should i look for "Internationalizing Applications" manual, please suggest.

Thanks & Regards!
Rajat.
 
It is in the Documentation Set, like he said. You should also look at the Error Handling manual for both old style and new style trapping of errors and handling them in a graceful fashion.
 
You must log in or register to reply here.
Back
Top