You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Michael Stanley <mi...@hotpop.com> on 2002/01/17 05:09:38 UTC
DefaultCookieParser null pointer exception
In my code I use the following to obtain a CookieParser
data.getCookies ()
I get the following error when Client Browser have cookies disabled -
java.lang.NullPointerException
at
org.apache.turbine.util.parser.DefaultCookieParser.setRunData(DefaultCoo
kieParser.java:156)
at
org.apache.turbine.services.rundata.DefaultTurbineRunData.getCookies(Def
aultTurbineRunData.java:518)
at
org.mitre.connectme.web.modules.screens.Default.doBuildTemplate(Default.
java:47)
Default.java:47 is where I call data.getCookies ()
Is there a way to test if a client has cookies enabled before calling
data.getCookies? Is this the desired behavior? I would think if
cookies were disabled, get cookies should just return a null cookie
parser. I'm try to avoid a try catch block here. There must be a more
elegant way. Thoughts?
Mike
RE: DefaultCookieParser null pointer exception
Posted by mstanley <ms...@mitre.org>.
> if(data.getCookies() != null)
> get a specific cookie
This would be the expected behavior, but I think this is a bug.
> Does just call data.getCookies alone throw a npe?
Data.getCookies throws a null pointer exception. I did a quick fix to
this by having code that looks like:
CookieParser cp = null
try
{
cp = data.getCookies();
}
catch (NullPointerException npe)
{
// handle no cookie support
}
if (cp != null)
{
// handle cookie support
}
This obviously isn't a good programmatic approach. I think that if
browsers don't support cookies data.getCookies() should return null
rather than throw an exception
Mike
> -----Original Message-----
> From: Michael Stanley [mailto:mikestanley@hotpop.com]
> Sent: 17 January 2002 04:10
> To: 'Turbine Users List'
> Subject: DefaultCookieParser null pointer exception
>
>
> In my code I use the following to obtain a CookieParser
>
>
> I get the following error when Client Browser have cookies disabled -
>
> java.lang.NullPointerException
> at
>
org.apache.turbine.util.parser.DefaultCookieParser.setRunData(DefaultCoo
> kieParser.java:156)
> at
>
org.apache.turbine.services.rundata.DefaultTurbineRunData.getCookies(Def
> aultTurbineRunData.java:518)
> at
>
org.mitre.connectme.web.modules.screens.Default.doBuildTemplate(Default.
> java:47)
>
> Default.java:47 is where I call data.getCookies ()
>
> Is there a way to test if a client has cookies enabled before calling
> data.getCookies? Is this the desired behavior? I would think if
> cookies were disabled, get cookies should just return a null cookie
> parser. I'm try to avoid a try catch block here. There must be a
more
> elegant way. Thoughts?
>
> Mike
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: DefaultCookieParser null pointer exception
Posted by Gareth Coltman <ga...@majorband.co.uk>.
Hmm. I seem to remember a similar problem, but I'm sure all we did was check
for null like:
if(data.getCookies() != null)
get a specific cookie
Does just call data.getCookies alone throw a npe?
-----Original Message-----
From: Michael Stanley [mailto:mikestanley@hotpop.com]
Sent: 17 January 2002 04:10
To: 'Turbine Users List'
Subject: DefaultCookieParser null pointer exception
In my code I use the following to obtain a CookieParser
I get the following error when Client Browser have cookies disabled -
java.lang.NullPointerException
at
org.apache.turbine.util.parser.DefaultCookieParser.setRunData(DefaultCoo
kieParser.java:156)
at
org.apache.turbine.services.rundata.DefaultTurbineRunData.getCookies(Def
aultTurbineRunData.java:518)
at
org.mitre.connectme.web.modules.screens.Default.doBuildTemplate(Default.
java:47)
Default.java:47 is where I call data.getCookies ()
Is there a way to test if a client has cookies enabled before calling
data.getCookies? Is this the desired behavior? I would think if
cookies were disabled, get cookies should just return a null cookie
parser. I'm try to avoid a try catch block here. There must be a more
elegant way. Thoughts?
Mike
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>