#26 No error check on command line arguments

[Kohsuke Kawaguchi]

Winstone apparently doesn't do much of error checks against arguments that the user supplies to the command line.

For example, see the following output for what happens if you forget the '=' in '--httpPort=8180':

akquinet@akquinet-laptop:~$ java -jar hudson.war --httpPort 8180
[Winstone 2007/10/28 20:26:48] - Beginning extraction from war file
[Winstone 2007/10/28 20:26:49] - No webapp classes folder found -
/tmp/winstone/hudson.war/WEB-INF/classes
hudson home directory: /home/akquinet/.hudson
[Winstone 2007/10/28 20:26:49] - Error starting listener instance
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at winstone.Launcher.spawnListener(Launcher.java:232)
at winstone.Launcher.<init>(Launcher.java:201)
at winstone.Launcher.main(Launcher.java:391)
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 Main.main(Main.java:50)
Caused by: java.lang.NumberFormatException: For input string: "true"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:447)
at java.lang.Integer.parseInt(Integer.java:497)
at winstone.HttpListener.<init>(HttpListener.java:55)

Simiarly, a typo like '--httpport=8180' doesn't produce any error at all.

I can see why it's done this way from implementation point of view, but this really hurts usability --- people are supposed to make mistakes, and when they do, it's the program's job to tell them where they made mistakes.

[Rick Knowles]

Logged In: YES
user_id=716353
Originator: NO

This is strictly speaking a feature request rather than a bug, but I can appreciate the point about usability.

The two cases you mention (case-sensitivity and no equals sign) are separate. The case sensitivity thing could be solved with a bit of wrapper code doing case-insensitive lookups, but the equals case would require far more code. Both are more than I'm willing to dedicate to user self-protection.

I agree the error message could be better, but I think the doc is really clear about the format. User babysitting has been knowingly traded away in favor of reduced size in the design goals (this is also documented, if not on the home page then on this list), so I guess what I'm looking for here is a compromise. Both of these together aren't worth more than maybe 5-8 extra lines of code application wide, so if someone can propose a change that would offer a user some kind of useful error covering both of these in less than 5 to 8 additional lines of code, I'm for it.

I unfortunately don't have any fix in mind, so I'll wait until someone suggests a good answer before doing anything about this.

[Kohsuke Kawaguchi]

Logged In: YES
user_id=179238
Originator: YES

The case insensitivity is not too important --- it was just meant to be an example of people using different names. The actual mode of failures that I see often is a typo, like missing 's' or some such.

I'll think about if there's any easy change that makes this work.