[Openroad-users] OpenROAD runtime error handling

Neil.Warnock at luminary.co.uk Neil.Warnock at luminary.co.uk
Wed Jun 20 02:13:08 EST 2007 

Enthusiasts could cobble something together from the exit trap functions that were introduced in 4.1  See PROCEXEC.SetExitTrap() and SESSIONOBJECT.ClearErrorFlag(). These can be nested, so with some form of home-grown exception *type* indicator, you could deal with an error there and then and/or (yes, and/or) bubble your way back to the appropriate exception 'catcher'. 

SetExitTrap is interesting. A sort of fusion between an event handler and a function/method. In reality it rolls back the call stack. A bit odd, but useful for error handling.

If you're using AppServer GSCPs and OSCA methods then watch out because they make use of exit traps for reporting errors back to clients. If you set another exit trap anywhere then YOU have to deal with the OSCA error there and then, or pass it back up the exit-trap chain explicitly with another EXIT. (FYI this is how multiply-nested AppServer services using OSCA work - however deep you are, EXIT statements bubble control back up to the client without passing go or collecting £200 etc.)

Not quite try..catch..finally but someone out there might be interested in taking this approach. And when OR is OS a real fanatic might decide to implement java-style exception handling built around these exit traps. Just thinking aloud.

Rgds, 
 

Neil Warnock
Luminary Solutions
Tel: +44 (0)845 371 4090
Mob: +44 (0)771 265 0291  
Email: Neil.Warnock at luminary.co.uk

For more information on Luminary go to http://www.luminary.co.uk
Luminary Solutions Limited Registered in England No 4854134 VAT Reg No. 829 3166 13
Registered Office: 16/17 Pavilion Business Park, Royds Hall Road, Leeds LS12 6AJ

 

-----Original Message-----
From: openroad-users-bounces at peerlessit.com [mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Bodo Bergmann
Sent: 19 June 2007 15:29
To: International OpenROAD Users
Subject: Re: [Openroad-users] OpenROAD runtime error handling

Java didn't take exception handling from Ada, but as part of the C++ syntax it is based on (it had been in C++ since 1990).
That's why the syntax in Java is similar to C++, but different to Ada.

Anyway, the original concepts are from Ada.

And I agree - it would be nice to have exception handling in OpenROAD.

BTW:
The exception syntax in Forte4GL
(another Windows4GL descendant like OpenROAD - now buried at Sun) is similar to Ada's syntax.

Bodo.

Bodo Bergmann
Senior Software Engineer
OpenROAD Worldwide Development
Ingres Corp.

-----Original Message-----
From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Michael Leo
Sent: Tuesday, June 19, 2007 3:42 PM
To: International OpenROAD Users
Subject: Re: [Openroad-users] OpenROAD runtime error handling

Jim,

Java borrowed the "try-catch" and exception scoping/bubbling mechanism from Ada.  It works very well, but like any sword, it has two sharp edges.

Java developers constantly "bury" exception information because they either don't understand exceptions, have never supported a production system, or don't have an exception handling architecture laid out.

It would be nice in OpenROAD.  The OR develop crowd seems to understand production engineering needs.  It would be a great tool in the toolbox.

Mike Leo

Antill, Jim wrote:
> Robert,
>
> A rather round-about way of doing it would be as follows:
>
> One thing I did a while back was to write a C# routine to monitor a 
> file, effectively doing the equivalent of a UNIX tail -f on the file.
> This worked, if I remember correctly, by an event being triggered when

> the file was changed. In fact I used it to redirect the w4gl.log file 
> to a window that stayed on top. (If you want the code I've probably 
> got it lying around
> somewhere.)
>
> This could be changed so that when a change to the file is detected 
> the new segment is checked for E_ chars. If any are found an external 
> event could be sent back to the OpenROAD application to say that an
error was received.
>
> I must admit to liking Java's try-catch error handling, something that

> would suit some parts of OpenROAD e.g 
> DynamicExpressionNotValidException rather than checking for NULL
dynexpr.
>
> Hope that's of some interest.
>
> Regards,
> Jim
>
> -----Original Message-----
> From: openroad-users-bounces at peerlessit.com
> [mailto:openroad-users-bounces at peerlessit.com]On Behalf Of Robert 
> Allely
> Sent: 18 June 2007 23:07
> To: International OpenROAD Users
> Subject: [Openroad-users] OpenROAD runtime error handling
>
>
> *************************************
>
> This e-mail has been received by the Revenue Internet e-mail service. 
> (IP)
>
> *************************************
>
> Is there a good way to trap run time errors - which seem to only 
> appear in the w4gl log and trace window - so the user can see that 
> something has gone wrong without having to look at the trace window? I

> was thinking of a setting like DBMSErrorPrinting .
>
> Robert Allely
> Ports of Auckland Ltd
> NZ
> ***
> This e-mail is privileged and confidential.  If you are not the 
> intended recipient please delete the message and notify the sender at 
> Ports of Auckland Limited.
> ***
>
> ________________________________________________________________
> OpenROAD-Users mailing list
>
> You can maintain your subscription here:
> http://www.peerlessit.com/mailman/listinfo/openroad-users
>
> To unsubscribe click on this link
> mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe
>
> To subscribe click on this link
> mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe
>
>
> ************************
>
> This message has been delivered to the Internet by the Revenue 
> Internet e-mail service (OP)
>
> *************************
>
> ________________________________________________________________
> OpenROAD-Users mailing list
>
> You can maintain your subscription here:
> http://www.peerlessit.com/mailman/listinfo/openroad-users
>
> To unsubscribe click on this link
> mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe
>
> To subscribe click on this link
> mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe
>
>
>   

________________________________________________________________
OpenROAD-Users mailing list

You can maintain your subscription here:
http://www.peerlessit.com/mailman/listinfo/openroad-users

To unsubscribe click on this link
mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe

To subscribe click on this link
mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe 

________________________________________________________________
OpenROAD-Users mailing list

You can maintain your subscription here:
http://www.peerlessit.com/mailman/listinfo/openroad-users

To unsubscribe click on this link
mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe

To subscribe click on this link
mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe

More information about the Openroad-users mailing list