Non-catchable errors - bug?

Posted by Lieven De Foor on 13-Jun-2014 03:28


Refering to this thread, the -clientConnectTimeout parameter to the CONNECT statement yields another error message than doing the CONNECT without that parameter.


Connection timeout for host localhost port 12345 transport TCP. 


Connection failure for host localhost port 12345 transport TCP. (9407) 

Also notice the absence of a Progress error number in the first case.

The worst part is that the first error is not caught in a catch block, nor does it set ERROR-STATUS:ERROR to true!

This is alarming. This means the ON ERROR is seemingly ignored for that error, and any subsequent statements are executed even after the error occurred.

Fortunately ERROR-STATUS:NUM-MESSAGES is set to 1 so this can be used as a workaround together with NO-ERROR...

I would assume this is a low level error occuring, which Progress should catch and rethrow as a Progress.Lang.Error.

Are there any other known cases of this behaviour, and should this be considered a bug?

All Replies

Posted by Lieven De Foor on 13-Jun-2014 09:19

Apparently this is a known issue, see KB

It's really baffling that Progress catalogs this as 'expected behaviour'.

For me this is a bug, and not a small one.

I should be able to reliably use ON ERROR/CATCH blocks to catch ALL errors, without the need to add NO-ERROR and check for NUM-ENTRIES everywhere (because Progress can't provide a list of statements that could exhibit this behavoir).

If I can write code to check for NUM-MESSAGES and in response throw a new error that can be caught, then why can't Progress do this on a lower level?

Posted by Peter van Dam on 13-Jun-2014 09:24

I totally agree, this is a very weak point of OpenEdge error handling.

Thanks for the reminder to always check NUM-MESSAGES in addition to adding CATCH blocks :-(

Posted by Donicello Lampe on 11-Jul-2014 09:55

Just to close the loop, the issues described here have been logged as a product defect. See:

This thread is closed