You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Igor Marakov <ig...@ivmsystems.com> on 2006/03/07 17:13:13 UTC

[betwixt] Exception suppression

I recently ran into the situation where betwixt is suppressing exceptions
during the translation.
I don't think it is a good idea. 
Enclosing application code should be aware that data that it expecting ain't
coming. Here is the example of the unsuccessful translation of the SQLJ
object that is coming from the DB and is supposed to be translated into the
normal java bean. Translation fails due to SQLException, but application
code is not getting any indication of it.

Question: Is there the way to switch this behavior off or limit it to
certain kinds of exceptions?

Thanks,
Igor

[DEBUG] com.my.framework.dao.bc4j.TranslatorImpl (translate) : START
translation com.my.framework.model.sqlj.MenuComponentC To java.util.List

[DEBUG] com.my.framework.dao.bc4j.TranslatorImpl (toXML) : Start toXML
translation

[ERROR] org.apache.commons.betwixt.expression.MethodExpression
(handleException) : [MethodExpression] Cannot evaluate expression 

java.lang.reflect.InvocationTargetException
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:585)
at
org.apache.commons.betwixt.expression.MethodExpression.evaluate(MethodExpres
sion.java:61)
at
org.apache.commons.betwixt.expression.IteratorExpression.evaluate(IteratorEx
pression.java:53)
at
org.apache.commons.betwixt.io.AbstractBeanWriter.writeElementContent(Abstrac
tBeanWriter.java:924)
at
org.apache.commons.betwixt.io.AbstractBeanWriter.writeElement(AbstractBeanWr
iter.java:738)
at
org.apache.commons.betwixt.io.AbstractBeanWriter.writeBean(AbstractBeanWrite
r.java:374)
at
org.apache.commons.betwixt.io.AbstractBeanWriter.writeBean(AbstractBeanWrite
r.java:243)
at
org.apache.commons.betwixt.io.AbstractBeanWriter.write(AbstractBeanWriter.ja
va:144)
at org.apache.commons.betwixt.io.BeanWriter.write(BeanWriter.java:190)
at com.my.framework.dao.bc4j.TranslatorImpl.toXML(TranslatorImpl.java:180)
at
com.my.framework.dao.bc4j.TranslatorImpl.translate(TranslatorImpl.java:135)
at
com.my.framework.dao.bc4j.DAOProxyInvocationHandler.invoke(DAOProxyInvocatio
nHandler.java:117)
at $Proxy0.getMenuComponents(Unknown Source)
at com.my.framework.dao.TestDAO_1.doMenuTest(TestDAO_1.java:125)
at com.my.framework.dao.TestDAO_1.doTests(TestDAO_1.java:73)
at com.my.framework.dao.TestDAO_1.main(TestDAO_1.java:54)

Caused by: java.sql.SQLException: Fail to construct descriptor: Invalid
arguments
at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
at oracle.sql.StructDescriptor.createDescriptor(StructDescriptor.java:155)
at oracle.sql.StructDescriptor.createDescriptor(StructDescriptor.java:130)
at oracle.jpub.runtime.MutableStruct.toDatum(MutableStruct.java:115)
at
com.my.framework.model.sqlj.MenuComponentT.toDatum(MenuComponentT.sqlj:110)
at oracle.jpub.runtime.Util._convertToOracle(Util.java:160)
at oracle.jpub.runtime.Util.convertToOracle(Util.java:146)
at oracle.jpub.runtime.MutableArray.getDatumElement(MutableArray.java:1273)
at oracle.jpub.runtime.MutableArray.getOracleArray(MutableArray.java:639)
at oracle.jpub.runtime.MutableArray.getObjectArray(MutableArray.java:810)
at oracle.jpub.runtime.MutableArray.getObjectArray(MutableArray.java:816)
at
com.my.framework.model.sqlj.MenuComponentC.getArray(MenuComponentC.java:76)

            ... 19 more

[DEBUG] com.my.framework.dao.bc4j.TranslatorImpl (toXML) : Resulting XML
<?xml version='1.0' ?>
  <elements/>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


RE: [betwixt] Exception suppression

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2006-03-07 at 17:21 -0500, Igor Marakov wrote:
> Robert,
> Do you have an approximate list of exceptions that SHOULD be handled by
> betwixt?

i'm not sure a general list is possible: the semantics of each method
mean that it would need to be done on a case-by-case basis. for some
APIs, an exception may indicate that the object is basically DOA, others
may throw exceptions when the input is outside acceptable bounds. there
are also some APIs which throw exceptions to communicate unusual
circumstances which are not necessarily errors. in this last case, users
may not want the mapping to terminate.

if i'd have designed the interface, i would probably have defaulted to
rethrowing all target exceptions but i'd have been wrong. this is
probably something that should be configurable: factor out a strategy
for processing the exception. have a switch in the configuration and let
users choose.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


RE: [betwixt] Exception suppression

Posted by Igor Marakov <ig...@ivmsystems.com>.
Robert,
Do you have an approximate list of exceptions that SHOULD be handled by
betwixt?

Thanks,
Igor

-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk] 
Sent: Tuesday, March 07, 2006 5:06 PM
To: Jakarta Commons Users List
Subject: Re: [betwixt] Exception suppression

On Tue, 2006-03-07 at 11:13 -0500, Igor Marakov wrote:
> I recently ran into the situation where betwixt is suppressing exceptions
> during the translation.
> I don't think it is a good idea. 
> Enclosing application code should be aware that data that it expecting
ain't
> coming. Here is the example of the unsuccessful translation of the SQLJ
> object that is coming from the DB and is supposed to be translated into
the
> normal java bean. Translation fails due to SQLException, but application
> code is not getting any indication of it.
> 
> Question: Is there the way to switch this behavior off or limit it to
> certain kinds of exceptions?

AFAIK not at the moment but this should be possible to add this
functionality without too much knowledge of the code. managing the
difficult JCL 1.1 release is taking most of my time ATM so not sure when
i'd find time to code this.

anyone want to volunteer to create a patch?

(i'd be glad to answer questions)

- robert



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Re: [betwixt] Exception suppression

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2006-03-07 at 11:13 -0500, Igor Marakov wrote:
> I recently ran into the situation where betwixt is suppressing exceptions
> during the translation.
> I don't think it is a good idea. 
> Enclosing application code should be aware that data that it expecting ain't
> coming. Here is the example of the unsuccessful translation of the SQLJ
> object that is coming from the DB and is supposed to be translated into the
> normal java bean. Translation fails due to SQLException, but application
> code is not getting any indication of it.
> 
> Question: Is there the way to switch this behavior off or limit it to
> certain kinds of exceptions?

AFAIK not at the moment but this should be possible to add this
functionality without too much knowledge of the code. managing the
difficult JCL 1.1 release is taking most of my time ATM so not sure when
i'd find time to code this.

anyone want to volunteer to create a patch?

(i'd be glad to answer questions)

- robert



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org