Re: Fw: [codec] base64Codec.decode and DecoderException
Hello, I saw your message on commons-dev and made a mental note to look into it, since I incorporated Base64 from commons-codec about a year ago. Quick answer: hey cool, no more meaningless exception to catch! Codec is only used currently in HEAD, and we haven't even released an alpha of 2.0 yet. I dug in a bit, and the DecoderException was thrown from Base64.decode(byte[]) until version 1.12 (Last November). This was before codec released 1.2. My solution will probably be to bump our dependency to 1.2 and remove the catch. Once I stop procrastinating and fax my CLA I will probably JFDI. :) -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ Adam R. B. Jack wrote: Folks, I posted this to the commons-dev [codec] list yesterday, but figured you might have views yourself (as a user of codec). I don't (personally) know the release history of codec, or if you'd mind not being able to compile your CVS HEAD code against older releases (assume any existed where it threw this exception), but one quick fix would be to compile out the try/catch. Clearly this is to your discretion, and depends upon what codec has released, and what they plan on releasing. If I get an answer on commons-dev I'll post it here. regards, Adam
Re: Fw: [codec] base64Codec.decode and DecoderException
Ryan, Thanks, nice research/write up. [I am copying Gump to keep a centralized archive, and I'll try to post a blog entry once complete.] So, theoretically the new code will still run against codec 1.12 (no signatures have explicitly changed), it just won't compile against it (seems reasonable). If this exception really is meaningless, and not thrown, no effect ought be felt to anybody other than developers/builders, right? Thanks for doing this. Hopefully an xmlrpc committer (with a CLA ;-) can perform the change. XMLRPC has dependees that would benefit from Gump coverage: http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/details.html#Project+Dependees and lots of knock on dependees: http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/details.html#Full+Project+Dependees regards, Adam - Original Message - From: Ryan Hoegg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 27, 2004 7:04 AM Subject: Re: Fw: [codec] base64Codec.decode and DecoderException Hello, I saw your message on commons-dev and made a mental note to look into it, since I incorporated Base64 from commons-codec about a year ago. Quick answer: hey cool, no more meaningless exception to catch! Codec is only used currently in HEAD, and we haven't even released an alpha of 2.0 yet. I dug in a bit, and the DecoderException was thrown from Base64.decode(byte[]) until version 1.12 (Last November). This was before codec released 1.2. My solution will probably be to bump our dependency to 1.2 and remove the catch. Once I stop procrastinating and fax my CLA I will probably JFDI. :) -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ Adam R. B. Jack wrote: Folks, I posted this to the commons-dev [codec] list yesterday, but figured you might have views yourself (as a user of codec). I don't (personally) know the release history of codec, or if you'd mind not being able to compile your CVS HEAD code against older releases (assume any existed where it threw this exception), but one quick fix would be to compile out the try/catch. Clearly this is to your discretion, and depends upon what codec has released, and what they plan on releasing. If I get an answer on commons-dev I'll post it here. regards, Adam
Fw: [codec] base64Codec.decode and DecoderException
Folks,
I posted this to the commons-dev [codec] list yesterday, but figured you
might have views yourself (as a user of codec). I don't (personally) know
the release history of codec, or if you'd mind not being able to compile
your CVS HEAD code against older releases (assume any existed where it threw
this exception), but one quick fix would be to compile out the try/catch.
Clearly this is to your discretion, and depends upon what codec has
released, and what they plan on releasing. If I get an answer on commons-dev
I'll post it here.
regards,
Adam
- Original Message -
From: Adam R. B. Jack [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 10:44 AM
Subject: [codec] base64Codec.decode and DecoderException
Folks,
An interested compatibility issue has surfaced from this:
http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/gump_work/build_ws-xmlrpc_ws-xmlrpc.html
/usr/local/gump/public/workspace/ws-xmlrpc/src/java/org/apache/xmlrpc/Defaul
tTypeFactory.java:133: exception org.apache.commons.codec.DecoderException
is never thrown in body of corresponding try statement
[javac] catch (DecoderException e) {
[javac] ^
This is the code:
public Object createBase64(String cdata)
{
try {
return base64Codec.decode(cdata.getBytes());
}
catch (DecoderException e) {
//TODO: consider throwing an exception here?
return new byte[0];
}
}
Now since exceptions are not part of the signature of methods, there is
probably no runtime issue here. If the exception is not going to be thrown
that is the same as it not actually being thrown, I guess. Still, there is
a
compile time problem and if one removes the catch they can't compile
against
older codec (assuming that was declared to throw it).
Can somebody provide the background information on this exception, from
this
method, and when (releases) it might've been available and removed? If
this
exception is never to be thrown again (and better, if it isn't thrown in
currently released code) then maybe we can just ask the ws-xmlrpc folks to
update.
BTW: I don't think there is a way to turn off this compiler error, is
there?
Would that be appropriate, even if possible?
regards,
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
