Thread: [Php-java-bridge-users] Confused about handling RuntimeExceptions

Hi,

I'm in the process of evaluating the PHP/Java Bridge.  My company wants to
use it to leverage an existing set of data model classes we have created
using Hibernate.  I've successfully set up a test that is working fine, but
I've come across something I'm concerned and a bit confused about and was
hoping the list could help me.

I've read the FAQ entry which states that all exceptions crossing the
boundary must be declared, as well as a thread in the mailing list archives
here:
http://sourceforge.net/mailarchive/message.php?msg_id=3921.39923.qm%40web505
08.mail.re2.yahoo.com

My concern is that this will prevent us from using the bridge in the way we
have envisioned, so I'm asking for advice on how to handle it.

We want to be able to perform arbitrary operations on our data model classes
within the scope of a Hibernate transaction, using a pattern like the
following:

$factory = getSessionFactory(); //Hibernate session factory
try {

  $factory->getCurrentSession()->beginTransaction();

  //arbitrary code here

  $factory->getCurrentSession()->getTransaction()->commit();

} catch (JavaException $ex) {
  $factory->getCurrentSession()->getTransaction()->rollback();
  throw $ex;
}

My concern is that there are several places within the arbitrary code
sections where we are calling methods that throw unchecked exceptions that
subclass RuntimeException.  Most of our exceptions will occur during the
commit, but not all of them.

Is our approach even feasible with the bridge?  We do not want to have to
declare "throws RuntimeException" on hundreds of methods in our data model
classes.  Is there some other approach we could take, perhaps passing our
arbitrary code as a closure to the java side and having a top level handler
for all exceptions on the java side of things?

I apologize if I am misunderstanding anything.  I have been programming Java
for a couple of years but so far I've only used basic servlets, no JEE
containers or anything more complicated so I'm basically looking for
guidance.

Thanks in advance!

Michael Sims

I would recommend to encapsulate your arbitrary code inside a java
method and simply call
the method from the php-side of the bridge, instead of rebuilding it in php.

~ dominik

On Wed, Sep 23, 2009 at 8:10 PM,
<php...@li...> wrote:
> Hi,
>
> I'm in the process of evaluating the PHP/Java Bridge.  My company wants to
> use it to leverage an existing set of data model classes we have created
> using Hibernate.  I've successfully set up a test that is working fine, but
> I've come across something I'm concerned and a bit confused about and was
> hoping the list could help me.
>
> I've read the FAQ entry which states that all exceptions crossing the
> boundary must be declared, as well as a thread in the mailing list archives
> here:
> http://sourceforge.net/mailarchive/message.php?msg_id=3921.39923.qm%40web505
> 08.mail.re2.yahoo.com
>
> My concern is that this will prevent us from using the bridge in the way we
> have envisioned, so I'm asking for advice on how to handle it.
>
> We want to be able to perform arbitrary operations on our data model classes
> within the scope of a Hibernate transaction, using a pattern like the
> following:
>
> $factory = getSessionFactory(); //Hibernate session factory
> try {
>
>  $factory->getCurrentSession()->beginTransaction();
>
>  //arbitrary code here
>
>  $factory->getCurrentSession()->getTransaction()->commit();
>
> } catch (JavaException $ex) {
>  $factory->getCurrentSession()->getTransaction()->rollback();
>  throw $ex;
> }
>
> My concern is that there are several places within the arbitrary code
> sections where we are calling methods that throw unchecked exceptions that
> subclass RuntimeException.  Most of our exceptions will occur during the
> commit, but not all of them.
>
> Is our approach even feasible with the bridge?  We do not want to have to
> declare "throws RuntimeException" on hundreds of methods in our data model
> classes.  Is there some other approach we could take, perhaps passing our
> arbitrary code as a closure to the java side and having a top level handler
> for all exceptions on the java side of things?
>
> I apologize if I am misunderstanding anything.  I have been programming Java
> for a couple of years but so far I've only used basic servlets, no JEE
> containers or anything more complicated so I'm basically looking for
> guidance.
>
> Thanks in advance!
>
> Michael Sims
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> php-java-bridge-users mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users
>

dominik wrote:
> I would recommend to encapsulate your arbitrary code inside a java
> method and simply call
> the method from the php-side of the bridge, instead of rebuilding it
> in php.

Thanks for the suggestion.  That doesn't really work for what we are wanting
to do, however.  We will have this arbitrary code spread all through our PHP
application, in the PHP code that handles user requests.  Much of the
arbitrary code in question will interact with parameters supplied from the
user, and the data model classes will be used in the view to render the
page.  While we could create dozens of methods for each different PHP page
that accepts various parameters, this would be a maintenance nightmare and
would defeat the purpose of trying to leverage this code in the first place.

Thanks again.

Michael

Hi,

In PHP/Java Bridge version 5.4.4.2 you can use the option
JAVA_PREFER_VALUES:

Download version 5.4.4.2, for example:
http://downloads.sourceforge.net/project/php-java-bridge/Binary%20package/php-java-bridge_5.4.4.2/JavaBridge.jar?use_mirror=dfn

Type java -jar JavaBridge.jar --version
-> 5.4.4.2

Type java -jar JavaBridge.jar SERVLET_LOCAL:8081 3 ""

Type php -n -dallow_url_include=On test.php

Test.php:

<?php
define ("JAVA_PREFER_VALUES", true);
require_once("http://localhost:8081/JavaBridge/java/Java.inc");

java_require("foo.jar");
try {
java("Foo")->call(false);
java("Foo")->call(true);
java("Foo")->call(false);
} catch (JavaException $e) {
  echo $e;
  }
?>

Foo.java:
public class Foo {
    public static void call(boolean b) {
if (b) throw new RuntimeException("bleh!");
    }
}

Please note that the option JAVA_PREFER_VALUES kills performance as it
checks for an exception after each call (I.e. each java call generates a
full network round-trip).
I have tested this against PHP/Java Bridge version 5.4.4.2. In 5.5.2 this
option doesn't work anymore (we'll re-enable it in a later 5.5 release).

However, I think it is better to handle unchecked exceptions in your own
Java class.

Regards,
Jost Boekemeier

On Sep 23, 2009 8:30 PM, <php...@li...>
wrote:

Hi,

I'm in the process of evaluating the PHP/Java Bridge.  My company wants to
use it to leverage an existing set of data model classes we have created
using Hibernate.  I've successfully set up a test that is working fine, but
I've come across something I'm concerned and a bit confused about and was
hoping the list could help me.

I've read the FAQ entry which states that all exceptions crossing the
boundary must be declared, as well as a thread in the mailing list archives
here:
http://sourceforge.net/mailarchive/message.php?msg_id=3921.39923.qm%40web505
08.mail.re2.yahoo.com

My concern is that this will prevent us from using the bridge in the way we
have envisioned, so I'm asking for advice on how to handle it.

We want to be able to perform arbitrary operations on our data model classes
within the scope of a Hibernate transaction, using a pattern like the
following:

$factory = getSessionFactory(); //Hibernate session factory
try {

 $factory->getCurrentSession()->beginTransaction();

 //arbitrary code here

 $factory->getCurrentSession()->getTransaction()->commit();

} catch (JavaException $ex) {
 $factory->getCurrentSession()->getTransaction()->rollback();
 throw $ex;
}

My concern is that there are several places within the arbitrary code
sections where we are calling methods that throw unchecked exceptions that
subclass RuntimeException.  Most of our exceptions will occur during the
commit, but not all of them.

Is our approach even feasible with the bridge?  We do not want to have to
declare "throws RuntimeException" on hundreds of methods in our data model
classes.  Is there some other approach we could take, perhaps passing our
arbitrary code as a closure to the java side and having a top level handler
for all exceptions on the java side of things?

I apologize if I am misunderstanding anything.  I have been programming Java
for a couple of years but so far I've only used basic servlets, no JEE
containers or anything more complicated so I'm basically looking for
guidance.

Thanks in advance!

Michael Sims


------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
php-java-bridge-users mailing list
php...@li...
https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users

Jost Boekemeier wrote:
> Please note that the option JAVA_PREFER_VALUES kills performance as it
> checks for an exception after each call (I.e. each java call
> generates a full network round-trip).

Hi,

Thanks for the response.  I did see the JAVA_PREFER_VALUES option in the
other thread I referenced and saw the warning about performance, so I want
to avoid that option if at all possible.

At this point my question is really more of a Java question and not so much
of a bridge question, but do you have any general pointers as to a pattern I
can use to handle these unchecked exceptions on the Java side without having
to sprinkle declarations all thoughout my Java code?

Would it be feasible to create a generic callback interface in Java and then
use java_closure() on the PHP side to create the equivalent of an anonymous
inner class which implements the callback interface?  I could then pass this
to a method on the Java side that executes the callback within the context
of a transaction, and additionally handles and wraps all exceptions with a
type that it explicitly declares.  Would this solve the issue without the
performance penalties that the JAVA_PREFER_VALUES option would?  Or am I
totally on the wrong track here?

Thanks again.

> Would it be feasible to create a generic callback interface in Java
> and then use java_closure() on the PHP side to create the equivalent
> of an anonymous inner class which implements the callback interface?
> I could then pass this to a method on the Java side that executes the
> callback within the context of a transaction, and additionally
> handles and wraps all exceptions with a type that it explicitly
> declares.  Would this solve the issue without the performance
> penalties that the JAVA_PREFER_VALUES option would?  Or am I totally
> on the wrong track here?

Sorry to followup to my own post here, but I tried this out and it does
work.  The code I have on the Java side is roughly equivalent to the
following:

public static void runInTransaction(Callback callback) throws
CallbackException {
  SessionFactory factory = getSessionFactory();

  try {
    factory.getCurrentSession().beginTransaction();
    callback.execute();
    factory.getCurrentSession().getTransaction().commit();
  } catch (RuntimeException e) {
    factory.getCurrentSession().getTransaction().rollback();
    throw new CallbackException(e);
  }
}

>From the PHP side:

class MyCallback {
  function execute() {
    //arbitrary code
  }
}

$callback = java_closure(new MyCallback(), null, new Java("Callback"));
try {
  java(...)->runInTransaction($callback);
} catch (JavaException $ex) {
  //handle exception
}

This seems to work.  Does this sidestep the exception handling issue?  Does
it significantly impact performance versus ensuring that all methods in the
arbitrary code declare all exceptions that they throw?

Thanks in advance...

Michael

Hi,

> This seems to work.

Not really.

If you want to catch unchecked exceptions, you need php/java bridge version
5.4.4.2 and set the JAVA_PREFER_VALUES option.

We will add a parameter to java_begin_document()/java_end_document() in
version 5.5 so that execution of the compiled document stops after the first
exception.

Regards,
Jost Boekemeier

On Sep 24, 2009 12:00 AM, <php...@li...>
wrote:

> Would it be feasible to create a generic callback interface in Java > and
then use java_closure() ...
Sorry to followup to my own post here, but I tried this out and it does
work.  The code I have on the Java side is roughly equivalent to the
following:

public static void runInTransaction(Callback callback) throws
CallbackException {
 SessionFactory factory = getSessionFactory();

 try {
   factory.getCurrentSession().beginTransaction();
   callback.execute();
   factory.getCurrentSession().getTransaction().commit();
 } catch (RuntimeException e) {
   factory.getCurrentSession().getTransaction().rollback();
   throw new CallbackException(e);
 }
}

>From the PHP side:

class MyCallback {
 function execute() {
   //arbitrary code
 }
}

$callback = java_closure(new MyCallback(), null, new Java("Callback"));
try {
 java(...)->runInTransaction($callback);
} catch (JavaException $ex) {
 //handle exception
}

This seems to work.  Does this sidestep the exception handling issue?  Does
it significantly impact performance versus ensuring that all methods in the
arbitrary code declare all exceptions that they throw?

Thanks in advance...

Michael

------------------------------------------------------------------------------
Come build with us!...

Jost Boekemeier wrote:
> Hi,
>
>> This seems to work.
>
> Not really.

Would you mind explaining why?  I don't need details, but just a brief
general explanation would really be appreciated.

> If you want to catch unchecked exceptions, you need php/java bridge
> version
> 5.4.4.2 and set the JAVA_PREFER_VALUES option.

Ok, I will test that approach and see if the performance is acceptable.
Thanks for your help and patience.

Michael

> Would you mind explaining why?

If you call a procedure or method that doesn't throw- or is declared to not
throw an exception, the procedure/method will be compiled to make its call
less expensive.

Regards,
Jost Boekemeier

On Sep 24, 2009 2:50 PM, <php...@li...>
wrote:

Jost Boekemeier wrote: > Hi, > >> This seems to work. > > Not really.
Would you mind explaining why?  I don't need details, but just a brief
general explanation would really be appreciated.

> If you want to catch unchecked exceptions, you need php/java bridge >
version > 5.4.4.2 and set t...
Ok, I will test that approach and see if the performance is acceptable.
Thanks for your help and patience.

Michael


------------------------------------------------------------------------------

Come build with us! The BlackBerry&reg; Developer Conference in SF, CA is
the only developer event y...

php...@li...

https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users

Hi again,

Forget what I've said. PHP has recently added a goto(!!) statement to php
5.3, so that a php 5.3 program can escape from a begin/end block w/o
generating an exception.

Therefore java_begin_document()/java_end_document() must be deprecated. --
Or we can keep them as dummy calls and simply remove the documentation.

I will document that if you want to catch unchecked exceptions, you must set
the JAVA_PREFER_VALUES option.

I think you'll have to bite the bullet and always throw checked exceptions
in all published API methods of your library. After that your library will
work well when used in Java containers such as EJB or the PHP/Java Bridge.

Regards,
Jost Boekemeier

On Sep 24, 2009 11:53 AM, "Jost Bekemeier" <jos...@go...>
wrote:

Hi,

> This seems to work.

Not really.

If you want to catch unchecked exceptions, you need php/java bridge version
5.4.4.2 and set the JAVA_PREFER_VALUES option.

We will add a parameter to java_begin_document()/java_end_document() in
version 5.5 so that execution of the compiled document stops after the first
exception.

Regards,
Jost Boekemeier

On Sep 24, 2009 12:00 AM, <php...@li...>
wrote:

> Would it be feasible to create a generic callback interface in Java > and
then use java_closure() ...

> > Sorry to followup to my own post here, but I tried this out and it does
> work.  The code I hav...

------------------------------------------------------------------------------
Come build with us!...

Jost Bekemeier wrote:
> I think you'll have to bite the bullet and always throw checked
> exceptions in all published API methods of your library. After that
> your library will work well when used in Java containers such as EJB
> or the PHP/Java Bridge.

Ok, I'll look into that as well.  My main issue with this is that almost all
of what I'm going to be dealing with are Java beans that are persisted via
Hibernate.  I'm going to be reading and setting properties mainly.  The
problem is that Hibernate backs the properties with persistent collections
that throw several unchecked exceptions.  Adding checked exception
declarations to all of these getters and setters is going to have a horrible
ripple effect in our existing code.  It may be that what I am intending to
do just isn't workable.

Let me make sure I understand the danger of using the unchecked exceptions.
I've seen you say that if an unchecked exception is thrown the behavior is
undefined.  Meaning that in some cases it might work "as expected", and the
exception will be thrown on the PHP side.  But in other cases the method
that threw the exception will return it instead of throwing it, and the code
will continue to execute.  Is this correct?

If so, this may not be a problem for me anyway.  I am not attempting to
catch unchecked exceptions in order to control the flow of the application.
In all cases, if an unchecked exception is thrown, I merely want to log it
and display an error message to the end user.  Since I'm mainly navigating
object graphs and chaining method calls, my code will still fail quickly
after an unchecked exception is thrown and ignored.  I will end up trying to
call a method on what was returned and the method will not exist, and the
execution will stop anyway.  It seems to me that the worst case scenario
will be that the exception or error on the PHP side will not be useful in
determining what went wrong.  In that case I could determine the source of
the problem via the log on the Java side.  Are my assumptions correct?

Jost Bekemeier wrote:
>> Would you mind explaining why?
>
> If you call a procedure or method that doesn't throw- or is declared
> to not throw an exception, the procedure/method will be compiled to
> make its call less expensive.

Ok, thanks for the explanation.

Michael

> a the log on the Java side.

Or via last_exception_get(), which returns the first exception not cleared
via last_exception_clear().

> Are my assumptions correct

Yes, correct.

If you add a throw java_last_exception_get();
java_last_exception_clear(); at the bottom of your try/catch block, you will
receive all exceptions with their stack traces from the back end.

The only problem is that the current Java.inc turns all undeclared
exceptions into fatal errors (see checkResult() in
java_ThrowExceptionProxyFactory) and that java_last_exception is currently
deprecated.

Regards,
Jost Boekemeier

On Sep 24, 2009 3:21 PM, <php...@li...>
wrote:

Jost Bekemeier wrote: > I think you'll have to bite the bullet and always
throw checked > exceptions...
Ok, I'll look into that as well.  My main issue with this is that almost all
of what I'm going to be dealing with are Java beans that are persisted via
Hibernate.  I'm going to be reading and setting properties mainly.  The
problem is that Hibernate backs the properties with persistent collections
that throw several unchecked exceptions.  Adding checked exception
declarations to all of these getters and setters is going to have a horrible
ripple effect in our existing code.  It may be that what I am intending to
do just isn't workable.

Let me make sure I understand the danger of using the unchecked exceptions.
I've seen you say that if an unchecked exception is thrown the behavior is
undefined.  Meaning that in some cases it might work "as expected", and the
exception will be thrown on the PHP side.  But in other cases the method
that threw the exception will return it instead of throwing it, and the code
will continue to execute.  Is this correct?

If so, this may not be a problem for me anyway.  I am not attempting to
catch unchecked exceptions in order to control the flow of the application.
In all cases, if an unchecked exception is thrown, I merely want to log it
and display an error message to the end user.  Since I'm mainly navigating
object graphs and chaining method calls, my code will still fail quickly
after an unchecked exception is thrown and ignored.  I will end up trying to
call a method on what was returned and the method will not exist, and the
execution will stop anyway.  It seems to me that the worst case scenario
will be that the exception or error on the PHP side will not be useful in
determining what went wrong.  In that case I could determine the source of
the problem via the log on the Java side.  Are my assumptions correct?

Jost Bekemeier wrote: >> Would you mind explaining why? > > If you call a
procedure or method that ...
Ok, thanks for the explanation.

Michael
------------------------------------------------------------------------------
Come build...

is the only developer event you need to attend this year. Jumpstart your
developing skills, take Bla...

php...@li...

https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users