More Error-Handling 101 - Forum - OpenEdge Development - Progress Community
 Forum

More Error-Handling 101

This question is answered

Hi.

In the code below, the doIt() always returns the unknown(?) value.

In the CATCH block I can see there is a value for c that has been fetched from e:getMessage(1).

I can make this work by putting my FIND and CATCH in its own DO block but I was just curious why it behaves the way it does. What nuance am I misunderstanding?

USING PROGRESS.lang.*.

FUNCTION doIt RETURNS CHARACTER():

  DEFINE VARIABLE c AS CHARACTER NO-UNDO.

  FIND Customer NO-LOCK
    WHERE Customer.Name = "xxx".

  RETURN c.

  CATCH e AS SysError:
    c = e:GetMessage(1).
    MESSAGE c
      VIEW-AS ALERT-BOX INFORMATION BUTTONS OK.
  END CATCH.

END FUNCTION.

MESSAGE doIt()
  VIEW-AS ALERT-BOX INFORMATION BUTTONS OK.

Jeff Ledbetter

Roundtable Product Architect

www.roundtable-software.com

Verified Answer
  • The RETURN c line does not execute. The error raised by the preceding line “jumps” to the CATCH block.
     
    You can verify this by using the debugger and stepping through the lines as they execute.
     
    You could add a RETURN c in the catch or even a finally block but you should be careful of doing that (there are  certain flow-of-control statements that don’t do what you’d think in CATCH/FINALLY blocks. There were changes in 11.4 (? I think; someone will correct me) to how such things work.
All Replies
  • The RETURN c line does not execute. The error raised by the preceding line “jumps” to the CATCH block.
     
    You can verify this by using the debugger and stepping through the lines as they execute.
     
    You could add a RETURN c in the catch or even a finally block but you should be careful of doing that (there are  certain flow-of-control statements that don’t do what you’d think in CATCH/FINALLY blocks. There were changes in 11.4 (? I think; someone will correct me) to how such things work.
  • Thanks.

    I did notice that behavior in the debugger but thought maybe it was a debugger quirk.  I incorrectly assumed that the RETURN would always get executed.

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

  • Third attempt at replying..

    Thanks. I did notice that behavior in the debugger but thought it was a quirk. I incorrectly assumed that the RETURN statement would always get executed.

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

  • If you wrap it in a

    finally:

      return c.

    end finally.

    it will probably be executed after the catch.

  • The FINALLY block is where true love would live.
  • It seems odd to put it in a FINALLY block. I think I'll keep my inner DO. :)

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

  • YEAH.  You did the right thing!  The FINALLY block was not meant to add code that would override behavior in the main block.  We should never even have allowed RETURN statements in FINALLY blocks.  So your feeling that it seemed odd means you have good instincts :-)

  • Hi Laura,

    Why would you not have allowed RETURN statement?

  • For the reason I said - the FINALLY block is meant to do clean-up code and the like.  It is not meant to override the behavior of the main block.  

    The really obnoxious case is when there is no error condition and the main code does RETURN 10 and the FINALLY block does RETURN 20.  We allow that!  What the heck does that mean?  The ABL will return 20 (the last statement wins).

    Another case, which is a variation of the one in this post is that there is an untrapped error in the main block (i.e., it is not caught).  And then the FINALLY statement does RETURN 10.  Well, if you wanted to ignore the error, why didn't you catch it or use NO-ERROR?  Just returning a good value from the FINALLY when an error happened that you didn't handle is a very bad coding practice.

    In C#, for example, they do not allow return statements in finally blocks to avoid all of this confusion.

  • I like that point of view from Laura! And I am glad, that Gilles' SonarSource has a rule for that condition

    Sent from Nine

    Von: Laura Stern <bounce-stern@community.progress.com>
    Gesendet: 03.05.2017 11:41 nachm.
    An: TU.OE.Development@community.progress.com
    Betreff: RE: [Technical Users - OE Development] More Error-Handling 101

    Update from Progress Community
    Laura Stern

    For the reason I said - the FINALLY block is meant to do clean-up code and the like.  It is not meant to override the behavior of the main block.  

    The really obnoxious case is when there is no error condition and the main code does RETURN 10 and the FINALLY block does RETURN 20.  We allow that!  What the heck does that mean?  The ABL will return 20 (the last statement wins).

    Another case, which is a variation of the one in this post is that there is an untrapped error in the main block (i.e., it is not caught).  And then the FINALLY statement does RETURN 10.  Well, if you wanted to ignore the error, why didn't you catch it or use NO-ERROR?  Just returning a good value from the FINALLY when an error happened that you didn't handle is a very bad coding practice.

    In C#, for example, they do not allow return statements in finally blocks to avoid all of this confusion.

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Hi Laura,

    I've never used a return statement in a finally block. I'm having trouble coming up with a valid use-case. Just out of curiosity I checked 1500 random finally statements from our code base. Not a single one of them uses return :-)

    So that makes you even more right ;-)

  • I’ve used it to return status codes (exit codes).
    Set a variable in the good and bad (catch blocks)  code and return the variable from the finally block.
     
    It’s not something you should be doing often though.
     
  • Hi Peter. Great example. Indeed not something you would do often...

    and if you do use it occasionally,  you might get into trouble when Laura decides to pull the plug on the feature :-)

  • I think the plug should be unppluged asap, before code begins to stack in the millions of cases..