ACS Error System Using it in JAVA Sohaila Lucero NRAO

JAVA developers will find the JAVA implementation of the ACS Error System similar to the exception handling in the JAVA Development Kit (JDK). Like C++ and Python, there are wrapper classes generated to help developers. These classes are used to translate between the native linked exception structure of JAVA (“caused-by”) and the awkward structure required for CORBA. These wrapper classes are all pre-pended by “AcsJ”.

Advantages of this implementation! With the “AcsJ-” exception wrapper classes, Java components can use standard JDK exception handling: –Exception inheritance hierarchy instead of type/code numbers: can catch exceptions by ErrorType –Easy daisy-chaining by adding cause exception in constructor –Seamless linking of java.lang.xyz exceptions or those from other packages (such as SAXParserException) Recall, CORBA does not support hierarchical exception structures.

The difference between “Inheritance Hierarchy” and “Daisy-chaining” Inheritance Hierarchy java.lang.Throwable java.lang.Exception Type1 Type2 Code1Ex Code2Ex Daisy-chaining (linking of exceptions) NullPointerException MyFirstException MyNextException

All code for the next example can be found in CVS in the following directory: ACS/LGPL/CommonSoftware/jcontexmpl

An Example! First the XML definitions of the errors. <Type xmlns:xsi=" xsi:noNamespaceSchemaLocation="ACSError.xsd" name="ErrorSystemExample" type="13" _prefix="alma"> <ErrorCode name="NothingCanBeScheduledError" shortDescription="Error in Scheduling System" description="Nothing could be scheduled error"/> <ErrorCode name="PipelineProcessingRequestError" shortDescription="Error with pipeline processing request" description="1"/> Must be unique to ALMA Assigned by Software Engineering group.

The previous XML document defines 1 error type, ErrorSystemExample, which contains these 2 error codes. NothingCanBeScheduledError and PipelineProcessingRequest

An Example! The IDL [automatically] generated from the previous XML. #ifndef _ErrorSystemExample_IDL_ #define _ErrorSystemExample_IDL_ #include #pragma prefix "alma" module ACSErr { // type const ACSErr::ACSErrType ErrorSystemExample = 13; }; // module ACSErr //more on next slide

module ErrorSystemExample { const ACSErr::ErrorCode NothingCanBeScheduledError = 0; const ACSErr::ErrorCode PipelineProcessingRequestError = 1; // excption for type: exception ErrorSystemExampleEx { ACSErr::ErrorTrace errorTrace; }; // excptions for codes: exception NothingCanBeScheduledErrorEx { ACSErr::ErrorTrace errorTrace; }; exception PipelineProcessingRequestErrorEx { ACSErr::ErrorTrace errorTrace; }; }; // module ErrorSystemExample #endif The error codes mapped to IDL Exceptions. Each containing the ErrorTrace from ACS. Notice the Ex appended to each.

An Example! Using the new exceptions in a IDL! Don’t forget to include the generated IDL file which has the exceptions defined! #include IDL Methods: void tryToScheduleSomething() raises (ErrorSystemExample::NothingCanBeScheduledErrorEx); void tryToProcessSomething() raises (ErrorSystemExample::PipelineProcessingRequestErrorEx); void usingWrapperClasses1() raises (ErrorSystemExample::NothingCanBeScheduledErrorEx); void usingWrapperClasses2(); Now that the error codes are mapped to IDL we can use them like any other exception in our IDL files

An Example! Simple implementations of the IDL methods. public void tryToScheduleSomething() throws NothingCanBeScheduledErrorEx { String schedblock = null; try { if(schedblock != null) { //Schedule it! } else { throw new NullPointerException("Can't scheduled a null SB!"); } } catch (NullPointerException e) {. AcsJNothingCanBeScheduledErrorEx e2 = new AcsJNothingCanBeScheduledErrorEx(e); throw e2.toNothingCanBeScheduledErrorEx(); } Since the SchedBlock is null we throw a NullPointer exceptiopn Then we catch that exception and using the generated wrapper classes we create our NothingCanBeScheduled exception with it. This creates a hierarchical exception chain. Then using a function in the wrapper class we convert our exception to something that CORBA will understand and we throw that exception.

An Example! continued… public void tryToProcessSomething() throws PipelineProcessingRequestErrorEx { //Trying to process something. try { tryToScheduleSomething(); } catch(NothingCanBeScheduledErrorEx e) { AcsJPipelineProcessingRequestErrorEx e2 = new AcsJPipelineProcessingRequestErrorEx(e); throw e2.toPipelineProcessingRequestErrorEx(); } Use our previous method to get an exception Using the wrapper classes for our other exception, we create an exception retaining the hierarchical structure. And again we convert it to an exception that CORBA will understand.

An Example! continued… public void usingWrapperClasses1() throws NothingCanBeScheduledErrorEx { try { throw new AcsJNothingCanBeScheduledErrorEx("Couldn't scheduled due to bad weather!"); `` } catch(AcsJErrorSystemExampleEx e){ throw ((AcsJNothingCanBeScheduledErrorEx)e).toNothingCanBeScheduledErrorEx(); } Using the wrapper classes we can take advantage of super/base classes. NOTE: This is only possible with the wrapper classes since CORBA does not support exception inheritance.

An Example! What objexp shows when an error is thrown!

An Example! continued… public void usingWrapperClasses2() { try { throw new AcsJNothingCanBeScheduledErrorEx("Testing printStackTrace!"); } catch(AcsJErrorSystemExampleEx e) { e.printStackTrace(); } Since the wrapper classes generated for our exceptions all inherit from the JAVA Exception class we can use the functions like printStackTrace()

An Example! What the stack trace looks like. alma.ErrorSystemExample.wrappers.AcsJNothingCanBeScheduledErrorEx: Testing printStackTrace! at alma.demo.ErrorSystemComp.ErrorSystemImpl.usingWrapperClasses2(ErrorSystemImpl.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at alma.acs.container.ContainerSealant.invoke(ContainerSealant.java:115) at $Proxy0.usingWrapperClasses2(Unknown Source) at alma.demo.ErrorSystemPOATie.usingWrapperClasses2(ErrorSystemPOATie.java:43) at alma.demo.ErrorSystemPOA._invoke(ErrorSystemPOA.java:46) at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source) at org.jacorb.poa.RequestProcessor.process(Unknown Source) at org.jacorb.poa.RequestProcessor.run(Unknown Source)

Too much to take in now? Everything from this presentation is discussed in more detail in Section 8 in the ACS Error System document found on the ACS webpage.