implementing an interface method with an extra exception

**Silvio Bierman** · Jul 17 '05, 10:34 PM

Re: implementing an interface method with an extra exception

"Murat Tasan" <tasan@eecs.cwr u.edu> wrote in message
news:Pine.SOL.4 .53.04011818025 10.11057@homer. ..[color=blue]
> 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 EncryptionExcep tion
>
> because EncryptionExcep tion is not a subclass of RuntimeExceptio n.
> this is a good thing, as i need it to be caught for proper error checking,
> so making EncryptionExcep tion a subclass of RuntimeExceptio n 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 EncryptionExcep tion 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
> mxt6@po.cwru.ed u
> tasan@eecs.cwru .edu
> murat.tasan@cwr u.edu
> http://genomics.cwru.edu
>[/color]

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 RuntimeExceptio n
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** · Jul 17 '05, 10:34 PM

Re: implementing an interface method with an extra exception

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
"controvers y" that i've heard about but never experienced (until now).
i suppose i'll just make EncryptionExcep tion a subclass of
UnsupportedOper ationException. ..

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:
[color=blue]
>
> "Murat Tasan" <tasan@eecs.cwr u.edu> wrote in message
> news:Pine.SOL.4 .53.04011818025 10.11057@homer. ..[color=green]
> > 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 EncryptionExcep tion
> >
> > because EncryptionExcep tion is not a subclass of RuntimeExceptio n.
> > this is a good thing, as i need it to be caught for proper error checking,
> > so making EncryptionExcep tion a subclass of RuntimeExceptio n 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 EncryptionExcep tion 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
> > mxt6@po.cwru.ed u
> > tasan@eecs.cwru .edu
> > murat.tasan@cwr u.edu
> > http://genomics.cwru.edu
> >[/color]
>
> 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 RuntimeExceptio n
> 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
>
>
>[/color]

--
Murat Tasan
mxt6@po.cwru.ed u
tasan@eecs.cwru .edu
murat.tasan@cwr u.edu

Genomics Core | School of Medicine | Case Western Reserve University

http://genomics.cwru.edu

Learn how the Genomics Core at Case Western Reserve University can provide you with a wide range of genomics and DNA/RNA quality control services.

**Bryan E. Boone** · Jul 17 '05, 10:34 PM

Re: implementing an interface method with an extra exception

You can always "nest" your exception in a RuntimeExceptio n.

throw new RuntimeExceptio n(new EncryptionExcep tion(...));

and get the "real" exception out by:

try {
....
....
}
catch(RuntimeEx ception e) {
EncryptionExcep tion ee = (EncryptionExce ption)e.getCaus e();
}

This example, of course, assumes that you know the RuntimeExceptio n actually
contains
the EncryptionExcep tion, but you get the idea.

-Bryan

"Murat Tasan" <tasan@eecs.cwr u.edu> wrote in message
news:Pine.SOL.4 .53.04011902005 20.11261@homer. ..[color=blue]
> 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
> "controvers y" that i've heard about but never experienced (until now).
> i suppose i'll just make EncryptionExcep tion a subclass of
> UnsupportedOper ationException. ..
>
> 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:
>[color=green]
> >
> > "Murat Tasan" <tasan@eecs.cwr u.edu> wrote in message
> > news:Pine.SOL.4 .53.04011818025 10.11057@homer. ..[color=darkred]
> > > i am implementing a custom version of the java.util.Map interface.
> > > my custom version does some encryption stuff when making modifications[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > the map via one of the 4 modification methods (put, putAll, remove,[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> > > clear).
> > > in doing this, i would like to also use one of my own exception[/color][/color][/color]
objects...[color=blue][color=green][color=darkred]
> > > so these 4 methods in the custom version should now also be defined[/color][/color][/color]
with:[color=blue][color=green][color=darkred]
> > > throws EncryptionExcep tion
> > >
> > > because EncryptionExcep tion is not a subclass of RuntimeExceptio n.
> > > this is a good thing, as i need it to be caught for proper error[/color][/color][/color]
checking,[color=blue][color=green][color=darkred]
> > > so making EncryptionExcep tion a subclass of RuntimeExceptio n 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[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > defined versions don't specify that EncryptionExcep tion is thrown.
> > >
> > > is it just me, or does this seem like a fairly large limitation in[/color][/color][/color]
java?[color=blue][color=green][color=darkred]
> > > is there an elegant way around this?
> > >
> > > thanks,
> > >
> > > murat
> > >
> > > --
> > > Murat Tasan
> > > mxt6@po.cwru.ed u
> > > tasan@eecs.cwru .edu
> > > murat.tasan@cwr u.edu
> > > http://genomics.cwru.edu
> > >[/color]
> >
> > If you think about this carefully this is exactly how it should be. If[/color][/color]
Java[color=blue][color=green]
> > where to support adding exception types to the throws-list then code[/color][/color]
calling[color=blue][color=green]
> > the function through the base-class (or interface) is unaware of an
> > exception that might be thrown. This is accepted upon for[/color][/color]
RuntimeExceptio n[color=blue][color=green]
> > subclasses but only for those.
> >
> > Remember that your implementation of Map could be passed to code that[/color][/color]
does[color=blue][color=green]
> > know anything else than a plain Map.
> >
> > Silvio Bierman
> >
> >
> >[/color]
>
> --
> Murat Tasan
> mxt6@po.cwru.ed u
> tasan@eecs.cwru .edu
> murat.tasan@cwr u.edu
> http://genomics.cwru.edu
>[/color]

**PerfectDayToChaseTornados** · Jul 17 '05, 10:34 PM

Re: implementing an interface method with an extra exception

"Murat Tasan" <tasan@eecs.cwr u.edu> wrote in message
news:Pine.SOL.4 .53.04011902005 20.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
| "controvers y" that i've heard about but never experienced (until now).
| i suppose i'll just make EncryptionExcep tion a subclass of
| UnsupportedOper ationException. ..
|
| 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

implementing an interface method with an extra exception

implementing an interface method with an extra exception

Comment

Comment

Comment

Comment