RE: Jk2: error handling and method signatures
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 :-) error handling good :) whether this is done by return codes, exceptions, etc., personally, i don't care. what i do care about is consistency -- the same error-handling techniques used throughout jk. 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. yes! an error string to explain exactly what went wrong would be great. 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. it all sounds pretty reasonable to me. -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
- Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
This is reminiscent of what the Subersion folks are doing for error handling. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
[EMAIL PROTECTED] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
[EMAIL PROTECTED] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
I meant causal, not casual. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
