on wish: central "on Procerror" Handling

Author: ulrichmerkel@web.de (ulrich-merkel)

Hi Rik (reply to uniface.communityzero.com/content/lists )

On one hand, a centralised "on procerror" sounds nice.

But I miss a way to include the context where the procerror occured.
Not as the context itself, but in the evaluation which actions needs to be taken.

An example:

it depends on the context
if $status of -2 or -4 after a retrieve
is an error or just an info.

I use a set of include procs after each call/activate to define what to do:

#include check_status:abort
#include check_status:give_info
#include check_status:log_only
#include check_status:ignore

They require only a single line and a codereview shows clear information
what is expected to be done by the application.

Success, Uli

P.S. the alternative would be someting like:
"#onerror resume/skip/abort/next"
but I would put this declarative always in front of each command
because some code-writer my put a different declarativ between my ones.



  1. And there is another thing:

    Do we want the proposed OnProcError trigger to fire allways and for each procerror?

    I think not, that would mean we have to rewrite all existing Uniface applications.
    All our current error handling would not work anymore.
    For example:
    retrieve/e "BLABLA"
    if ($status < 0)
       message/nobeep "No Blabla found"
    The code after the retrieve statement would never be fired because the read comes back with -1 or -2.
    So you would be FORCED to change all of your sourcecode.

    It would be nice to have an OnProcError trigger that fires for unhandled proc errors,
    but I don't see much possibilities for the compiler to find out for sure whether a procerror will be handled in the next few staements or not.

    So my opinion: nice idea, but it is not gonna work.

    Author: Theo Neeskens (tneeskens@itblockz.nl)
  2. Theo,

    I see what you are saying but I think it could still work.

    If the OnProcError trigger passed the $procerror & $procerrorcontext out then it could be used 'going forward' to handle all the $procerror not already caught.

    For example in my app I always have $procerror handling as an #include after every newinstance or activate statement but not after proc entry calls.

    if I call an entry with the wrong params then I could have a selectcase within the OnProcError trigger that handled that error but not those that are already handled after an activate error



    Author: AyeJayUU (awilkins1@btinternet.com)
  3. Hi Andrew,

    still a bit confused about the sequence of events:
    when should the OnProcerror trigger be fired?

    We have come across something which set $procerror and $procerrorcontext.
    Afterwards, we have a #include to handle $procerror.

    But at the moment the $procerror occurs (i assume OnProcerror Trigger should be fired now),
    the processor does not know what may happen in a couple of statements.

    I think this would call a syntax like the Java
    TRY       ......do something....
    CATCH .....handle exceptions...

    Success, Uli



    Author: ulrich-merkel (ulrichmerkel@web.de)
  4. I think OnProcError should fire in the event of a proc error

    It should handle some errors (not necessarily all) and  return $procerror.

    Then U should continue processing any code after the proc statement that caused the $procerror

    OnProcError just needs to fire and handle (via selectcase) whatever errors you have not already coded for in your proc after the e.g. activate


    activate [rubbish]

    #include mylib:capture ; [rubbish activate]


    call rubbish

    [I don't have any code to handle rubbish proc]


    selectcase $procerror

    case [rubbish proc]

       New code




    Author: AyeJayUU (awilkins1@btinternet.com)
  5. Hi Andrew,

    the flow of executable code as far as I see it:

    processing codeline "activate [rubbish]"

    $procerror is raised during that activate
    raising $procerror triggers the "onProcError"
    "onProcError" is executed

    processing the next codeline, maybe "blabla" or "#include mylib:capture ; [rubbish activate]"

    WIthout some syntax construct like TRY-CATCH the executable code does not care about the next codeline.

    Success, Uli



    Author: ulrich-merkel (ulrichmerkel@web.de)
  6. My impression is that the OnprocError trigger will fire after e.g. a bad activate.

    it will have some conditional code to handle certain errors - nullifying $procerror along the way

    if none of the conditional handling matches the original $procerror then as a default it will pass out the $procerror and $procerrorcontext/

    The code after the activate can then handle any $procerror not dealt with by the trigger.


    Seems simple enough without any new syntax etc

    Author: AyeJayUU (awilkins1@btinternet.com)
  7. Hi Andrew,

    now I see where we differ.

    You see it as some kind of general activated routine
    where you can specify some general handling scenarios
    and leave all the other cases to some local coding.

    I saw the "on Procerror" as some default handler
    if no special treatment of $procerror is specified.
    So it depends on local implementation.

    Success, that this reaches the top wishes and stays on top,



    Author: ulrich-merkel (ulrichmerkel@web.de)
  8. Possibly a "general" event-Trigger?

    Like the debugger: You can input in the breakpoints just a condition (without any component-name), and if this condition is true, the debugger pops up. Something similar can be done for uniface.... A kind of async-Trigger: If the condition you define is true, the defined actions will be executed immidietly. So you can define your $procerror, $dberror and whatever you like... Projects, which don't use it, can leave it empty.

    But I guess, this solution can slow down the complete system...



    Author: gypsilon (wva@gypsilon.de)
  9. an excellent article about error handling
    (pros and cons and different strategies)

    It's C++ but because of "same functionality, same strategy"
    there are many things which are true for uniface as well:

    Success, Uli

    Author: ulrich-merkel (ulrichmerkel@web.de)
  10. Personally speaking, I'd prefer a try/ throw/ catch mechanism as per Java & C# for dealing with context-sensitive errors (i.e. the ones you explicitly want to cater for) rather than the older "on error resume etc." constructs that you find in Visual Basic etc. You might then add the option of the catch explictly raising a generic error which would be handled by the normal on error triggers.

    I can see the point in general error handling mechanisms as well, but my guess is that they'd be of most use when you want to terminate processing, rather than clean up and continue processing (although i'm sure there would be exceptions).

    - David

    Author: dakerman (david.akerman@compuware.com)