Jk2: error handling and method signatures

[co...@covalent.net]

Hi,

One more change I want to do in jk2 is better error handling. Most of us
spent enough time with java that using an 'int' is very uncomfortable :-)

My proposal is to use jk_env in the same 'style' as in JNI programming.
Each jk method will have as the first parameter a jk_env *env ( that
requires just a bit of regexp ).

Before the first call to a jk method, we'll use a jk_getEnv, which will
return a (pooled) jk_env.

env will have "errorString", "errorFile", eventually a method throw() that
will set the things. This would allow mod_jk to report the exact problem.

Exactly the same method is used in jni - a jni worker could actually
wrap JNIEnv.

I also believe the code will be easier to read this way.

This is obviously not 'required' - we can live without it. Please let me
know what you think - I implement it pretty quickly.

Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: error handling and method signatures

[co...@covalent.net]

On Wed, 12 Dec 2001, Bill Barker wrote:

> If you are talking about status codes, I'm -1.  That should be passed
> through from Tomcat without change.
>
> If Tomcat hangs up, then there is almost no useful information available, so
> there isn't much to report.  If the client hangs up, then like jk1, we
> should just stop processing and return OK to Apache.
>
> I'm probably just misunderstanding what situations you are trying to handle
> here, so if you can be a little bit more verbose, I'll probably change my
> vote.

I want mod_jk to display a page saying 'tomcat is temporary down, please
make sure tomcat is started' or something like that. Right now we just
display 'jakarta-handler not available' - and we have no way to know what
was the exact cause for that ( bad config, tomcat not started, something
else ).

It's true, the module that detects an error is logging the error, but the
information is lost for the caller. For example memory allocation errors
or null pointer exceptions should be treated diferently from connection
errors.

is_recoverable is an ugly way to let called code pass some info up ( i.e.
if the error was 'really bad' or not ).

It's pretty hard to come with a list of why exceptions are usefull and
list the use-cases :-)

Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: error handling and method signatures

[co...@covalent.net]

On Wed, 12 Dec 2001, Bill Barker wrote:

> I'm probably just misunderstanding what situations you are trying to handle
> here, so if you can be a little bit more verbose, I'll probably change my
> vote.

More details:

jk_env will replace all jk_logger_t parameters. All methods will follow
the  pattern:

  method( jk_env *env, jk_foo *_this, ... other params ... );

The env will be guaranteed to be used single-threaded ( i.e. either each
thread has a per/thread env, or we use the objCache, or any other
mechanism ). mod_jk will get an instance and release it after it's done.

The env will be have few uses:

- save the error message and details. When an error is detected, besides
returning the right status ( or NULL for methods returning a real object
and not using ** ), we'll call env->throw() method. This will replace the
current jkLog( JK_ERROR, ... ) ( which will be implemented in throw() )
from each method. Caller could either check the rc, or env->error ( I
prefer the second because it's more consistent )

- logger. In addition, because env is per/thread we could do some tricks
here too ( right now it works because printf is synchronized - or I think
so ).

- temp pool/storage. Things like map, logger, etc need some temp storage.
Right now they either malloc/free or use some other ugly tricks ( per
stack, etc ).


Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: error handling and method signatures

[Bill Barker <wb...@wilshire.com>]

If you are talking about status codes, I'm -1.  That should be passed
through from Tomcat without change.

If Tomcat hangs up, then there is almost no useful information available, so
there isn't much to report.  If the client hangs up, then like jk1, we
should just stop processing and return OK to Apache.

I'm probably just misunderstanding what situations you are trying to handle
here, so if you can be a little bit more verbose, I'll probably change my
vote.
----- Original Message -----
From: <co...@covalent.net>
To: <to...@jakarta.apache.org>
Sent: Wednesday, December 12, 2001 9:12 PM
Subject: Jk2: error handling and method signatures


> Hi,
>
> One more change I want to do in jk2 is better error handling. Most of us
> spent enough time with java that using an 'int' is very uncomfortable :-)
>
> My proposal is to use jk_env in the same 'style' as in JNI programming.
> Each jk method will have as the first parameter a jk_env *env ( that
> requires just a bit of regexp ).
>
> Before the first call to a jk method, we'll use a jk_getEnv, which will
> return a (pooled) jk_env.
>
> env will have "errorString", "errorFile", eventually a method throw() that
> will set the things. This would allow mod_jk to report the exact problem.
>
> Exactly the same method is used in jni - a jni worker could actually
> wrap JNIEnv.
>
> I also believe the code will be easier to read this way.
>
> This is obviously not 'required' - we can live without it. Please let me
> know what you think - I implement it pretty quickly.
>
> Costin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jk2: error handling and method signatures

[Bill Barker <wb...@wilshire.com>]

----- Original Message -----
From: <co...@covalent.net>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, December 13, 2001 12:28 PM
Subject: Re: Jk2: error handling and method signatures


> So far I have a -1, if Bill doesn't change his vote we'll keep the current
> mechanism. But if we are going to change error handling, I think jni style
> is better for our needs.
Sorry, I've had a busy morning. I'm won over to +1.
>
> Costin
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jk2: error handling and method signatures

[Daniel Rall <dl...@finemaltcoding.com>]

I meant causal, not casual.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jk2: error handling and method signatures

[Daniel Rall <dl...@finemaltcoding.com>]

<co...@covalent.net> writes:

> On Thu, 13 Dec 2001, Daniel Rall wrote:
>
>> http://svn.collab.net/repos/svn/trunk/subversion/include/svn_error.h
>
> It seems they are using a struct that is returned instead of a simple int,
> as status. It does solve the problem of propagating more info.

In practice, I've found casual error information to be extremely
useful.  It seems that I'm not the only one, as it's been incorporated
into the JDK for version 1.4.  Catalina, Commons Util, Ant, and other
project employ this technique with good results.  It's just another
tool to consider (which might not apply equally well to all
situations).

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jk2: error handling and method signatures

[co...@covalent.net]

On Thu, 13 Dec 2001, Daniel Rall wrote:

> Here's what Subversion does for error progation:
>
> http://svn.collab.net/repos/svn/trunk/subversion/include/svn_error.h
>
> Could propogate that in the suggested env.

It seems they are using a struct that is returned instead of a simple int,
as status. It does solve the problem of propagating more info.

However I would rather use the jni style and use the env parameters. I
think it has few benefits over svn:

- return values can be used ( I believe it can be easier to read than ** )

- it also provides access to logging, object registry, etc. We have to
pass this anyway.

- it's close to java - most people here are using java most of the time,
some have already experience with jni, so it would 'feel' more natural

- I believe it is a bit cleaner ( but that's a matter of taste ).


So far I have a -1, if Bill doesn't change his vote we'll keep the current
mechanism. But if we are going to change error handling, I think jni style
is better for our needs.

Costin




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jk2: error handling and method signatures

[Daniel Rall <dl...@finemaltcoding.com>]

<co...@covalent.net> writes:

> On Thu, 13 Dec 2001, Daniel Rall wrote:
>
>> This is reminiscent of what the Subersion folks are doing for error
>> handling.
>
> Could you give a URL ? If it was already invented... ( I was thinking to
> use a subset of what's 'invented' in jni, I believe there are
> quite a few people who'll feel 'familiar' with this and it's natural for
> java programmers ).

Here's what Subversion does for error progation:

http://svn.collab.net/repos/svn/trunk/subversion/include/svn_error.h

Could propogate that in the suggested env.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jk2: error handling and method signatures

[co...@covalent.net]

On Thu, 13 Dec 2001, Daniel Rall wrote:

> This is reminiscent of what the Subersion folks are doing for error
> handling.

Could you give a URL ? If it was already invented... ( I was thinking to
use a subset of what's 'invented' in jni, I believe there are
quite a few people who'll feel 'familiar' with this and it's natural for
java programmers ).

Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jk2: error handling and method signatures

[Daniel Rall <dl...@finemaltcoding.com>]

This is reminiscent of what the Subersion folks are doing for error
handling.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>