How2 catch ALL exceptions? A responsibles uniface-coders no longer nightmare

once, it was a trademark of a responsible uniface coder to check $status after each commend to react on all kind of exceptions. Now I learned from CPWR employees contributions that this is no longer enough. Think CPWR should present us the “new way” to catch all exceptions. 101223: Mike Taylor brought some light to it so we can sleep in peace

Since I started with uniface 1992, it was best practice to write your code like:

a-command
if ($status < 0)
some-errorhandling
endif

******************** breaking NEWS *******************************

Ready for Christmas, there is a word of relief:

miketaylor  
Dec 23, 2010 10:20 PM
…. If the developer has not redirected the return value, myHandle->myOperation(param), the return value will be placed in the default location ($status), under these circumstances you can continue error checking in the way you always have ….

***********************************************************************

 

What do we hear now from high respected people:

Comment Icon jhuggins1 Edit Comment Delete Comment
Dec 6, 2010 11:02 AM
Re. $status being enough, this is not always true. An example is when using handles to execute an operation. In this case, the handle acts more like a function and returns the value rather than explicity setting $status.
Comment Icon jhuggins1 Edit Comment Delete Comment
Dec 7, 2010 5:54 PM
Hi Uli, just to clarify my comment re. handles, if the physical act of calling a handle fails due to e.g. a wrong operation name, $status and $procerror are set. If you are however looking at the in-lined return value from a handle call, then $status is not set. Beware of implicitly setting $status as doing so clears/resets $procerror etc…. Maybe start a separate thread specifically about handles their use.

So what is the “new way” of still beeing a responsible uniface-coder and pick up all kind of exceptions?

SUccess, Uli

P.S. This article adresses a serious problem and is no playing-games. Exceptions which can not be detected are timebombs.

 

Addendum 101216:

Comment Icon jhuggins1 Edit Comment Delete Comment
Dec 15, 2010 12:59 PM
Hi Uli, my comments here are being shown out of context. These comments simply reiterate the documented handle functionality, which clearly describes $status in relation to handles.

Hi Jas, you describe at least one scenario where checking $status is not enough to catch all exception situations.

May be other scenarios exist as well where we don’t see irregular situations.

So our old “if ($status < 0)” needs improvement.

checking $status plus $procerror plus …..

If we have a COMPLETE list and changed our include-proc,  we can sleep well again.

So let’s get it on.

 

 

0 thoughts on “How2 catch ALL exceptions? A responsibles uniface-coders no longer nightmare”

  1. Hi, One of the advantages of handles is the ability to in-line the call to an operation allowing you to directly capture its return value, vStatus = myHandle->myOperation(param), or to use the return value as part of an evaluation, if (myHandle->myOperation(param) &lt 0 ). If these techniques are used $status will not be set as the return value will have been redirected to the assigned location, allowing you to implement a more direct and compact form of error checking than you traditional could. If the developer has not redirected the return value, myHandle->myOperation(param), the return value will be placed in the default location ($status), under these circumstances you can continue error checking in the way you always have. Unfortunately, the documentation could be clearer on this point and will be updated to reflect the functionality.

  2. Hi Mike, thanks for clearing this up. It looks like we can still rely on checking $status (except in situations we have created ourself). Think the same situation we face using “returnS string” to define a function, $status is useless. Success, Uli

Leave a Reply