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"
   return(-1)
endif
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.

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

Andrew

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

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

so

activate [rubbish]

#include mylib:capture ; [rubbish activate]

...

call rubbish

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

<OnProcError>

selectcase $procerror

case [rubbish proc]

   New code

elsecase

   return($procerror)

endselectcase

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

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

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,

Uli

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...

W

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:
www.codeproject.com/KB/cpp/cppexceptionsproetcontra.aspx

Success, Uli

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