Hi,
Refering to this thread, the -clientConnectTimeout parameter to the CONNECT statement yields another error message than doing the CONNECT without that parameter.
with:
Connection timeout for host localhost port 12345 transport TCP.
without:
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?
Apparently this is a known issue, see KB knowledgebase.progress.com/.../P84367
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?
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 :-(
Just to close the loop, the issues described here have been logged as a product defect. See: