By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 1,902 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

implementing an interface method with an extra exception

P: n/a
i am implementing a custom version of the java.util.Map interface.
my custom version does some encryption stuff when making modifications to
the map via one of the 4 modification methods (put, putAll, remove, and
clear).
in doing this, i would like to also use one of my own exception objects...
so these 4 methods in the custom version should now also be defined with:
throws EncryptionException

because EncryptionException is not a subclass of RuntimeException.
this is a good thing, as i need it to be caught for proper error checking,
so making EncryptionException a subclass of RuntimeException is not an
acceptable solution.

the problem is, when i try to compile i get the error that my custom
methods cannot implement the defined versions in java.util.Map because the
defined versions don't specify that EncryptionException is thrown.

is it just me, or does this seem like a fairly large limitation in java?
is there an elegant way around this?

thanks,

murat

--
Murat Tasan
mx**@po.cwru.edu
ta***@eecs.cwru.edu
mu*********@cwru.edu
http://genomics.cwru.edu

Jul 17 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a

"Murat Tasan" <ta***@eecs.cwru.edu> wrote in message
news:Pine.SOL.4.53.0401181802510.11057@homer...
i am implementing a custom version of the java.util.Map interface.
my custom version does some encryption stuff when making modifications to
the map via one of the 4 modification methods (put, putAll, remove, and
clear).
in doing this, i would like to also use one of my own exception objects...
so these 4 methods in the custom version should now also be defined with:
throws EncryptionException

because EncryptionException is not a subclass of RuntimeException.
this is a good thing, as i need it to be caught for proper error checking,
so making EncryptionException a subclass of RuntimeException is not an
acceptable solution.

the problem is, when i try to compile i get the error that my custom
methods cannot implement the defined versions in java.util.Map because the
defined versions don't specify that EncryptionException is thrown.

is it just me, or does this seem like a fairly large limitation in java?
is there an elegant way around this?

thanks,

murat

--
Murat Tasan
mx**@po.cwru.edu
ta***@eecs.cwru.edu
mu*********@cwru.edu
http://genomics.cwru.edu


If you think about this carefully this is exactly how it should be. If Java
where to support adding exception types to the throws-list then code calling
the function through the base-class (or interface) is unaware of an
exception that might be thrown. This is accepted upon for RuntimeException
subclasses but only for those.

Remember that your implementation of Map could be passed to code that does
know anything else than a plain Map.

Silvio Bierman
Jul 17 '05 #2

P: n/a
thanks for the input. actually, a short while after posting i realized
that as well. i guess the problem comes back to the runtime exception
"controversy" that i've heard about but never experienced (until now).
i suppose i'll just make EncryptionException a subclass of
UnsupportedOperationException...

i'm not a fan of this, but it seems to be the only way.

thanks,

murat

On Mon, 19 Jan 2004, Silvio Bierman wrote:

"Murat Tasan" <ta***@eecs.cwru.edu> wrote in message
news:Pine.SOL.4.53.0401181802510.11057@homer...
i am implementing a custom version of the java.util.Map interface.
my custom version does some encryption stuff when making modifications to
the map via one of the 4 modification methods (put, putAll, remove, and
clear).
in doing this, i would like to also use one of my own exception objects...
so these 4 methods in the custom version should now also be defined with:
throws EncryptionException

because EncryptionException is not a subclass of RuntimeException.
this is a good thing, as i need it to be caught for proper error checking,
so making EncryptionException a subclass of RuntimeException is not an
acceptable solution.

the problem is, when i try to compile i get the error that my custom
methods cannot implement the defined versions in java.util.Map because the
defined versions don't specify that EncryptionException is thrown.

is it just me, or does this seem like a fairly large limitation in java?
is there an elegant way around this?

thanks,

murat

--
Murat Tasan
mx**@po.cwru.edu
ta***@eecs.cwru.edu
mu*********@cwru.edu
http://genomics.cwru.edu


If you think about this carefully this is exactly how it should be. If Java
where to support adding exception types to the throws-list then code calling
the function through the base-class (or interface) is unaware of an
exception that might be thrown. This is accepted upon for RuntimeException
subclasses but only for those.

Remember that your implementation of Map could be passed to code that does
know anything else than a plain Map.

Silvio Bierman


--
Murat Tasan
mx**@po.cwru.edu
ta***@eecs.cwru.edu
mu*********@cwru.edu
http://genomics.cwru.edu

Jul 17 '05 #3

P: n/a
You can always "nest" your exception in a RuntimeException.

throw new RuntimeException(new EncryptionException(...));

and get the "real" exception out by:

try {
....
....
}
catch(RuntimeException e) {
EncryptionException ee = (EncryptionException)e.getCause();
}

This example, of course, assumes that you know the RuntimeException actually
contains
the EncryptionException, but you get the idea.

-Bryan
"Murat Tasan" <ta***@eecs.cwru.edu> wrote in message
news:Pine.SOL.4.53.0401190200520.11261@homer...
thanks for the input. actually, a short while after posting i realized
that as well. i guess the problem comes back to the runtime exception
"controversy" that i've heard about but never experienced (until now).
i suppose i'll just make EncryptionException a subclass of
UnsupportedOperationException...

i'm not a fan of this, but it seems to be the only way.

thanks,

murat

On Mon, 19 Jan 2004, Silvio Bierman wrote:

"Murat Tasan" <ta***@eecs.cwru.edu> wrote in message
news:Pine.SOL.4.53.0401181802510.11057@homer...
i am implementing a custom version of the java.util.Map interface.
my custom version does some encryption stuff when making modifications to the map via one of the 4 modification methods (put, putAll, remove, and clear).
in doing this, i would like to also use one of my own exception objects... so these 4 methods in the custom version should now also be defined with: throws EncryptionException

because EncryptionException is not a subclass of RuntimeException.
this is a good thing, as i need it to be caught for proper error checking, so making EncryptionException a subclass of RuntimeException is not an
acceptable solution.

the problem is, when i try to compile i get the error that my custom
methods cannot implement the defined versions in java.util.Map because the defined versions don't specify that EncryptionException is thrown.

is it just me, or does this seem like a fairly large limitation in java? is there an elegant way around this?

thanks,

murat

--
Murat Tasan
mx**@po.cwru.edu
ta***@eecs.cwru.edu
mu*********@cwru.edu
http://genomics.cwru.edu


If you think about this carefully this is exactly how it should be. If Java where to support adding exception types to the throws-list then code calling the function through the base-class (or interface) is unaware of an
exception that might be thrown. This is accepted upon for RuntimeException subclasses but only for those.

Remember that your implementation of Map could be passed to code that does know anything else than a plain Map.

Silvio Bierman


--
Murat Tasan
mx**@po.cwru.edu
ta***@eecs.cwru.edu
mu*********@cwru.edu
http://genomics.cwru.edu

Jul 17 '05 #4

P: n/a

"Murat Tasan" <ta***@eecs.cwru.edu> wrote in message
news:Pine.SOL.4.53.0401190200520.11261@homer...
| thanks for the input. actually, a short while after posting i realized
| that as well. i guess the problem comes back to the runtime exception
| "controversy" that i've heard about but never experienced (until now).
| i suppose i'll just make EncryptionException a subclass of
| UnsupportedOperationException...
|
| i'm not a fan of this, but it seems to be the only way.
|
| thanks,
|
| murat
|
<snip>

Murat, why not write your class as a wrapper class, that way you can throw
any exceptions you like, you can still name the methods the same (e.g..add,
get etc) and call these methods on it's own internal Map with your extra
processing, or does your code rely on your class extending Map?
--
-P

Jul 17 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.