failsoft, external functions and exception handlers

[ConvertFromOldNGs]

by johnmunro >> Fri, 17 Jan 2003 11:45:18 GMT

We have just created a C++ DLL consisting of some code that takes a long time to run in Jade but is quick in C.

It ocurred to me that we could make the system "failsoft". The system would by default try to use the DLL, and if it was missing for whatever reason, instead of raising an exception would fall back to the native Jade version of the code.

The method I'm using is as below:

processFile(fileName : String) : Boolean;
varsbegin

on Exception do processFileExceptionHandler(exception);

return call processFile(fileName);

return processFileNative(fileName);
end;

So in order for this to work, the exception handler needs to return Ex_Continue or Ex_Resume_Next, but the "Entry point not in library" exception is non-continuable and non-resumable.

I can't work out how to arrange the exception handler and methods to be able to try something and if that fails do something else...

I had a similar problem with ActiveX controls which weren't installed on client machines, and solved it with app.isActiveXClassIdRegistered(Class.GUID).

Unfortunately I can't find anything similar for external functions, like app.isEntryPointInLibrary or something...


John Munro

---
Synergist Limited - Home of FileVision
The Bioscience Innovation Centre
Cowley Road, Cambridge, UK
CB4 0DS

Telephone: +44 (0) 1223 478200
Fax: +44 (0) 1223 477969
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact Synergist Limited immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. Synergist Limited cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform Synergist Limited.

[ConvertFromOldNGs]

by allistar >> Fri, 17 Jan 2003 20:34:51 GMT

Hi John,
You could try doing this:

vars
wasLibraryFound: Boolean;begin

wasLibraryFound := true;
on Exception do processFileExceptionHandler(exception, wasLibraryFound); return call processFile(fileName);
epilog
if (not waslibraryFound) then
return processFileNative(fileName);
endif;
end;

And the exception handler:

processFileExceptionHandler(ex: Exception, wasLibraryFound: Boolean output):Integer;
begin

wasLibraryFound := false;
return Ex_Abort_Action;
end;

This way in the epilog of the original method you are catching whether or not an exception occurs, and if it does you call the slow version.

Let me know if this does the trick,
Regards,
Allistar.

[ConvertFromOldNGs]

by johnmunro >> Mon, 20 Jan 2003 10:44:29 GMT

This way in the epilog of the original method you are catching whether or not an exception occurs, and if it does you call the slow version.

It nearly works - if the DLL is missing, Jade runs the native code as we want it to. The problem is that this code is not called in isolation - it is part way through loading a file into our image viewer. So when we return Ex_Abort_Action it not only aborts the call to the DLL, but the entire image loading process. It would work perfectly if the exception handler was limited in scope to the method it was set up in, or if we could set process.isInTransactionState to false (a dangerous thing to allow us to do, I know).

John Munro

---
Synergist Limited - Home of FileVision
The Bioscience Innovation Centre
Cowley Road, Cambridge, UK
CB4 0DS

Telephone: +44 (0) 1223 478200
Fax: +44 (0) 1223 477969
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact Synergist Limited immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. Synergist Limited cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform Synergist Limited.

[ConvertFromOldNGs]

by allistar >> Mon, 20 Jan 2003 22:21:15 GMT

This way in the epilog of the original method you are catching whether or not an exception occurs, and if it does you call the slow version.

It nearly works - if the DLL is missing, Jade runs the native code as we want it to. The problem is that this code is not called in isolation - it is part way through loading a file into our image viewer. So when we return Ex_Abort_Action it not only aborts the call to the DLL, but the entire image loading process. It would work perfectly if the exception handler was limited in scope to the method it was set up in, or if we could set process.isInTransactionState to false (a dangerous thing to allow us to do, I know).

What you are trying to achieve should be possible, the key is in the exception handler return code. Ex_Abort_Action will roll the call
stack back to the event that caused it. It's a pain that you can't use Ex_Return_Next, as that's really what you want. It seems to me that
this particular exception should be resumable.

A particularly hacky way of doing this is to start up another call
stack by spawning another thread to do the dll call. Then when the exception happens only that thread will get rolled back, not the
original thread. You would need to get the original thread to wait
until the spawned thread has finished doing it's thing (by way of a notification). Something like this:

Main thread:
- spawn 2nd thread using app.startAppMethod
- wait until that thread has finished (by looping until a condition is true)
- if the 2nd thread failed, call the slow Jade method.
- continue as per normal

Spawned thread:
- arm exception handler
- try dll code
- on an exception send a notification to the main thread telling it
that the dll call failed, return Ex_Abort_Action.
- otherwise send a notification to the main thread telling it we succeeded.

It's not a nice way of doing things, but sometimes you have to resort
to ugly code to achieve the desired result. There will be a
performance expense of doing it this way too.

Regards,
Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer
Auckland, NEW ZEALAND

Greentree International,
Developer of Greentree Financial Software. ------------------------------------------------------------------

[ConvertFromOldNGs]

by johnmunro >> Tue, 21 Jan 2003 11:35:42 GMT

A particularly hacky way of doing this is to start up another call stack by spawning another thread to do the dll call.

Hm, the point of the DLL was to increase performance, and I don't think this'll do much towards that goal. Thanks for your help, it looks like I've got to harangue Jade Support some.

John Munro

---
Synergist Limited - Home of FileVision
The Bioscience Innovation Centre
Cowley Road, Cambridge, UK
CB4 0DS

Telephone: +44 (0) 1223 478200
Fax: +44 (0) 1223 477969
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact Synergist Limited immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. Synergist Limited cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform Synergist Limited.

[ConvertFromOldNGs]

by brendan1 >> Tue, 21 Jan 2003 12:17:58 GMT

John,
The idea of using Ex_Abort_Action is OK but needs to be modified a bit. As you say, to abort unilaterally skips any code after the call to the method invoking the library entry point. Also, what if you are in transaction state etc.

How about the following:

1. To keep things tidy, define a controller class to contain a wrapping method for each entry point you intend to use in the library.
2. Define a Boolean property, libraryExists say, on the controller. This will be initialised to false by default when the instance is created.
3. Since you are in control of the dll, write another entry point in the dll (called Exists, for example) which does nothing and takes no parameters. 4. Write and init method on the controller which sends a user notification (Response_Cancel) to the controller. The userNotification event (now a "throw away" event) calls the Exists entry point in the dll in the way described by Alistair earlier (set exception handler etc). In the epilog, if the exception was NOT raised, set the boolean property libraryExists to true.
5. The wrapper methods for each entry point test the boolean libraryExists and call the Jade version if false, the library version if true.

If the library does exist, the jade version will be called until the notification invoked by the init method on the controller has been actioned.

Cheers, Brendan

[ConvertFromOldNGs]

by johnmunro >> Tue, 21 Jan 2003 15:31:54 GMT

That worked perfectly, and it packages quite small and simple

Thanks

John