Transcript Java - ESO

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!
Recall, CORBA does not support hierarchical exception structures.
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)
The difference between
“Inheritance Hierarchy” and “Daisy-chaining”
Inheritance Hierarchy
java.lang.Throwable
Daisy-chaining
(linking of exceptions)
<inherits>
MyNextException
java.lang.Exception
<caused-by>
<inherits>
Type1
Type2
<inherits>
<inherits>
Code1Ex Code2Ex
Code1Ex
MyFirstException
<caused-by>
Code2Ex
NullPointerException
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.
<?xml version="1.0" encoding="UTF-8"?>
<Type xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="ACSError.xsd"
name="ErrorSystemExample"
type="13"
Must be unique to ALMA
_prefix="alma">
Assigned by Software Engineering group.
<!-- these are the codes for the ERRORS -->
<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"/>
</Type>
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 <acserr.idl>
#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 <ErrorSystemExample.idl>
IDL Methods:
void tryToScheduleSomething()
raises (ErrorSystemExample::NothingCanBeScheduledErrorEx);
Now that the error codes are mapped to IDL
we can use them like any other exception in our IDL files
void tryToProcessSomething()
raises (ErrorSystemExample::PipelineProcessingRequestErrorEx);
void usingWrapperClasses1()
raises (ErrorSystemExample::NothingCanBeScheduledErrorEx);
void usingWrapperClasses2();
An Example!
Simple implementations of the IDL methods.
public void tryToScheduleSomething() throws NothingCanBeScheduledErrorEx {
String schedblock = null;
try {
Since the SchedBlock is
if(schedblock != null) {
null we throw a NullPointer
//Schedule it!
exceptiopn
} else {
throw new NullPointerException("Can't scheduled a null SB!");
}
} catch (NullPointerException e) {
Then we catch that exception and using the
generated wrapper classes we create our
AcsJNothingCanBeScheduledErrorEx e2
NothingCanBeScheduled exception with it.
= new AcsJNothingCanBeScheduledErrorEx(e);
This creates a hierarchical exception chain.
.
throw e2.toNothingCanBeScheduledErrorEx();
}
}
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();
Use our previous method to
get an exception
} catch(NothingCanBeScheduledErrorEx e) {
AcsJPipelineProcessingRequestErrorEx e2 = new
AcsJPipelineProcessingRequestErrorEx(e);
throw e2.toPipelineProcessingRequestErrorEx();
}
}
And again we convert it to an exception
that CORBA will understand.
Using the wrapper classes for
our other exception, we create
an exception retaining the
hierarchical structure.
An Example!
continued…
public void usingWrapperClasses1() throws NothingCanBeScheduledErrorEx {
try {
throw new AcsJNothingCanBeScheduledErrorEx("Couldn't scheduled due to bad weather!");
Using the wrapper classes we can take
advantage of super/base classes.
``
} catch(AcsJErrorSystemExampleEx e){
NOTE: This is only possible with the wrapper
classes since CORBA does not support
exception inheritance.
throw ((AcsJNothingCanBeScheduledErrorEx)e).toNothingCanBeScheduledErrorEx();
}
}
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.