Checked Exceptions!

[OvErboRed]

I just read a whole bunch of threads on microsoft.publi c.dotnet.* regarding
checked exceptions (the longest-running of which seems to be <cJQQ9.4419
$j94.834878@new s02.tsnz.net>.

My personal belief is that checked exceptions should be required in .NET. I
find that many others share the same views as I do. It is extremely
frustrating to have to work around this with hacks like Abstract ADO.NET
and CLRxLint (which still don't solve the problem).

On the other hand, it seems that most of the @microsoft.com posters are
ignoring or adamantly refusing to accept the argument (and fact) that
exception specification is as essential as parameter and return type
specification when it comes to creating well-defined interfaces.

I'm wondering if there's any hope at all for MS to introduce checked
exceptions into an upcoming iteration of .NET. What would it take to move
MS to action (or at least more serious consideration) on such issues as
this? I realize that at this point, a shift at such a fundamental level
will not be easy, but perhaps this will be something to look forward to in
..NET 2.

[Kapil Sachdeva]

Re: Checked Exceptions!

Fully agree to your views on checked exceptions. I program in Java also and
really appreciate this notion

"OvErboRed" <overboredNO@SP AMoverbored.net > wrote in message
news:Xns93CB9B5 064749yangstaov erbored@207.46. 248.16...[color=blue]
> I just read a whole bunch of threads on microsoft.publi c.dotnet.*[/color]
regarding[color=blue]
> checked exceptions (the longest-running of which seems to be <cJQQ9.4419
> $j94.834878@new s02.tsnz.net>.
>
> My personal belief is that checked exceptions should be required in .NET.[/color]
I[color=blue]
> find that many others share the same views as I do. It is extremely
> frustrating to have to work around this with hacks like Abstract ADO.NET
> and CLRxLint (which still don't solve the problem).
>
> On the other hand, it seems that most of the @microsoft.com posters are
> ignoring or adamantly refusing to accept the argument (and fact) that
> exception specification is as essential as parameter and return type
> specification when it comes to creating well-defined interfaces.
>
> I'm wondering if there's any hope at all for MS to introduce checked
> exceptions into an upcoming iteration of .NET. What would it take to move
> MS to action (or at least more serious consideration) on such issues as
> this? I realize that at this point, a shift at such a fundamental level
> will not be easy, but perhaps this will be something to look forward to in
> .NET 2.[/color]

[mia lanui]

Re: Checked Exceptions!

It would be a good thing, especially if the people you work with don't check
for exceptions, or much else of anything...

"OvErboRed" <overboredNO@SP AMoverbored.net > wrote in message
news:Xns93CB9B5 064749yangstaov erbored@207.46. 248.16...[color=blue]
> I just read a whole bunch of threads on microsoft.publi c.dotnet.*[/color]
regarding[color=blue]
> checked exceptions (the longest-running of which seems to be <cJQQ9.4419
> $j94.834878@new s02.tsnz.net>.
>
> My personal belief is that checked exceptions should be required in .NET.[/color]
I[color=blue]
> find that many others share the same views as I do. It is extremely
> frustrating to have to work around this with hacks like Abstract ADO.NET
> and CLRxLint (which still don't solve the problem).
>
> On the other hand, it seems that most of the @microsoft.com posters are
> ignoring or adamantly refusing to accept the argument (and fact) that
> exception specification is as essential as parameter and return type
> specification when it comes to creating well-defined interfaces.
>
> I'm wondering if there's any hope at all for MS to introduce checked
> exceptions into an upcoming iteration of .NET. What would it take to move
> MS to action (or at least more serious consideration) on such issues as
> this? I realize that at this point, a shift at such a fundamental level
> will not be easy, but perhaps this will be something to look forward to in
> .NET 2.[/color]

[Kieran Benton]

Re: Checked Exceptions!

Trouble is that this can break components that rely on functions that
specify what exceptions they throw.

For instance, if MusicPlayer.exe uses a function PlayMusic() in
MusicPlayer.dll and PlayMusic is changed and now can throw a IOException,
unless MusicPlayer.exe is completely recompiled the code will break. Sorry
for the simplistic explanation but its beginning to get late! :)

I think thats what someone from MS said a while ago neway. I agree that it
is useful, maybe just a check at compile time or in debug builds or
something?

Hope this helps
Kieran

"OvErboRed" <overboredNO@SP AMoverbored.net > wrote in message
news:Xns93CB9B5 064749yangstaov erbored@207.46. 248.16...[color=blue]
> I just read a whole bunch of threads on microsoft.publi c.dotnet.*[/color]
regarding[color=blue]
> checked exceptions (the longest-running of which seems to be <cJQQ9.4419
> $j94.834878@new s02.tsnz.net>.
>
> My personal belief is that checked exceptions should be required in .NET.[/color]
I[color=blue]
> find that many others share the same views as I do. It is extremely
> frustrating to have to work around this with hacks like Abstract ADO.NET
> and CLRxLint (which still don't solve the problem).
>
> On the other hand, it seems that most of the @microsoft.com posters are
> ignoring or adamantly refusing to accept the argument (and fact) that
> exception specification is as essential as parameter and return type
> specification when it comes to creating well-defined interfaces.
>
> I'm wondering if there's any hope at all for MS to introduce checked
> exceptions into an upcoming iteration of .NET. What would it take to move
> MS to action (or at least more serious consideration) on such issues as
> this? I realize that at this point, a shift at such a fundamental level
> will not be easy, but perhaps this will be something to look forward to in
> .NET 2.[/color]

[Keith Patrick]

Re: Checked Exceptions!

I'd settle for accurate exception specifications in the documentation! I
can't count the number of times I still get unhandled exceptions in code
that catches every documented exception.

[Andre]

Re: Checked Exceptions!

Another issue is the runtime performance cost involved with checked
exceptions.

-Andre

Kieran Benton wrote:[color=blue]
> Trouble is that this can break components that rely on functions that
> specify what exceptions they throw.
>
> For instance, if MusicPlayer.exe uses a function PlayMusic() in
> MusicPlayer.dll and PlayMusic is changed and now can throw a IOException,
> unless MusicPlayer.exe is completely recompiled the code will break. Sorry
> for the simplistic explanation but its beginning to get late! :)
>
> I think thats what someone from MS said a while ago neway. I agree that it
> is useful, maybe just a check at compile time or in debug builds or
> something?
>
> Hope this helps
> Kieran
>
> "OvErboRed" <overboredNO@SP AMoverbored.net > wrote in message
> news:Xns93CB9B5 064749yangstaov erbored@207.46. 248.16...
>[color=green]
>>I just read a whole bunch of threads on microsoft.publi c.dotnet.*[/color]
>
> regarding
>[color=green]
>>checked exceptions (the longest-running of which seems to be <cJQQ9.4419
>>$j94.834878@n ews02.tsnz.net> .
>>
>>My personal belief is that checked exceptions should be required in .NET.[/color]
>
> I
>[color=green]
>>find that many others share the same views as I do. It is extremely
>>frustrating to have to work around this with hacks like Abstract ADO.NET
>>and CLRxLint (which still don't solve the problem).
>>
>>On the other hand, it seems that most of the @microsoft.com posters are
>>ignoring or adamantly refusing to accept the argument (and fact) that
>>exception specification is as essential as parameter and return type
>>specificati on when it comes to creating well-defined interfaces.
>>
>>I'm wondering if there's any hope at all for MS to introduce checked
>>exceptions into an upcoming iteration of .NET. What would it take to move
>>MS to action (or at least more serious consideration) on such issues as
>>this? I realize that at this point, a shift at such a fundamental level
>>will not be easy, but perhaps this will be something to look forward to in
>>.NET 2.[/color]
>
>
>[/color]

[Keith Patrick]

Re: Checked Exceptions!

Managed code itself has a runtime performance hit as well, but the
protections it provides make it well worth it. I think of checked
exceptions similarly. Newer hardware can always take care of that :)

[Jon Skeet]

Re: Checked Exceptions!

Andre <food_crazy@hot mail.com> wrote:[color=blue]
> Another issue is the runtime performance cost involved with checked
> exceptions.[/color]

Checked exceptions are (or at least can be) checked at compile time
rather than runtime. Why should it have any performance implications at
runtime?

If the runtime were required to check that only the declared checked
exceptions could be thrown, that would create a slight performance cost
at runtime when loading the type/method, but needn't create any other
cost as far as I can see.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet/

If replying to the group, please do not mail me too

[Dave]

Re: Checked Exceptions!

How about a third alternative...

A compiler could examine all the exceptions thrown from a method and bake
the data of the exception types thrown directly into the metadata of the
method. Tools could then examine this and use it as they see fit.

One example of how this could be used is to use auto-completion to provide
catch blocks for some or all of the known exceptions thrown within a scope.

Regardless of how tools could use this data the advantage is that it is not
required and it is backwardly compatible with all existing assemblies. If
the data is not present then the tools would find zero exceptions thrown; as
assemblies get updated by tools that understand the new metadata, it would
automatically get put into them. Also, since the data is generated each time
the assembly is compiled it avoids the problem of the documentation not
matching the code, and it avoids a runtime hit.

DaveL


"Eric Gunnerson [MS]" <ericgu@online. microsoft.com> wrote in message
news:OB3f9mjWDH A.3232@tk2msftn gp13.phx.gbl...[color=blue]
> I think there are a couple of important considerations here.
>
> The first is whether checked exceptions are a good idea in principle.[/color]
There[color=blue]
> are lots of different opinions here - some people think that checked
> exceptions are essential, some think that checked exceptions are good but
> should be used in conjunction with unchecked exceptions, and some think[/color]
that[color=blue]
> checked exceptions cause more problems than they solve. For view against
> checked exceptions from the Java (and C++) world, I suggest looking at[/color]
Bruce[color=blue]
> Eckel's position at
> http://www.mindview.net/Etc/Discussi...ckedExceptions.
>
> The second is what it would actually mean to implement checked exceptions[/color]
on[color=blue]
> the .NET platform. There are two ways you could do it.
>
> You could implement checked exceptions in C# only, but using libraries
> written in other languages would be strange, in that they would not have
> exception information. This probably would not work very well.
>
> The second option would be to implement checked exceptions throughout[/color]
..NET.[color=blue]
> That would mean that all languages would be required to support checked
> exceptions. I think it's fair to say that if Microsoft took that position,
> it would not be a popular one amongst the language implementors, both[/color]
inside[color=blue]
> and outside of Microsoft. We've tried to limit the requirements we impose[/color]
on[color=blue]
> other languages as much as practical, and checked exceptions would be a[/color]
bit[color=blue]
> imposition.
>
> Because of these considerations, checked exceptions are an issue where we
> can't satisfy all of our users. We will continue to explore the issue in[/color]
the[color=blue]
> future.
>
> --
> Eric Gunnerson
>
> Visit the C# product team at http://www.csharp.net
> Eric's blog is at http://blogs.gotdotnet.com/ericgu/
>
> This posting is provided "AS IS" with no warranties, and confers no[/color]
rights.[color=blue]
> "OvErboRed" <overboredNO@SP AMoverbored.net > wrote in message
> news:Xns93CB9B5 064749yangstaov erbored@207.46. 248.16...[color=green]
> > I just read a whole bunch of threads on microsoft.publi c.dotnet.*[/color]
> regarding[color=green]
> > checked exceptions (the longest-running of which seems to be <cJQQ9.4419
> > $j94.834878@new s02.tsnz.net>.
> >
> > My personal belief is that checked exceptions should be required in[/color][/color]
..NET.[color=blue]
> I[color=green]
> > find that many others share the same views as I do. It is extremely
> > frustrating to have to work around this with hacks like Abstract ADO.NET
> > and CLRxLint (which still don't solve the problem).
> >
> > On the other hand, it seems that most of the @microsoft.com posters are
> > ignoring or adamantly refusing to accept the argument (and fact) that
> > exception specification is as essential as parameter and return type
> > specification when it comes to creating well-defined interfaces.
> >
> > I'm wondering if there's any hope at all for MS to introduce checked
> > exceptions into an upcoming iteration of .NET. What would it take to[/color][/color]
move[color=blue][color=green]
> > MS to action (or at least more serious consideration) on such issues as
> > this? I realize that at this point, a shift at such a fundamental level
> > will not be easy, but perhaps this will be something to look forward to[/color][/color]
in[color=blue][color=green]
> > .NET 2.[/color]
>
>[/color]

[Eric Gunnerson [MS]]

Re: Checked Exceptions!

We are working to make the information about what exceptions could happen
more available.

In many cases, however, you can't derive it directly from code, because
you're operating through interfaces, and you don't know at compile time what
object is implementing them. Dynamic create of objects has the same problem,
as does factory methods that return a base class.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
"Dave" <kdlevine@wi.rr .com> wrote in message
news:%23MYLhsmW DHA.1580@tk2msf tngp13.phx.gbl. ..[color=blue]
> How about a third alternative...
>
> A compiler could examine all the exceptions thrown from a method and bake
> the data of the exception types thrown directly into the metadata of the
> method. Tools could then examine this and use it as they see fit.
>
> One example of how this could be used is to use auto-completion to provide
> catch blocks for some or all of the known exceptions thrown within a[/color]
scope.[color=blue]
>
> Regardless of how tools could use this data the advantage is that it is[/color]
not[color=blue]
> required and it is backwardly compatible with all existing assemblies. If
> the data is not present then the tools would find zero exceptions thrown;[/color]
as[color=blue]
> assemblies get updated by tools that understand the new metadata, it would
> automatically get put into them. Also, since the data is generated each[/color]
time[color=blue]
> the assembly is compiled it avoids the problem of the documentation not
> matching the code, and it avoids a runtime hit.
>
> DaveL
>
>
> "Eric Gunnerson [MS]" <ericgu@online. microsoft.com> wrote in message
> news:OB3f9mjWDH A.3232@tk2msftn gp13.phx.gbl...[color=green]
> > I think there are a couple of important considerations here.
> >
> > The first is whether checked exceptions are a good idea in principle.[/color]
> There[color=green]
> > are lots of different opinions here - some people think that checked
> > exceptions are essential, some think that checked exceptions are good[/color][/color]
but[color=blue][color=green]
> > should be used in conjunction with unchecked exceptions, and some think[/color]
> that[color=green]
> > checked exceptions cause more problems than they solve. For view against
> > checked exceptions from the Java (and C++) world, I suggest looking at[/color]
> Bruce[color=green]
> > Eckel's position at
> > http://www.mindview.net/Etc/Discussi...ckedExceptions.
> >
> > The second is what it would actually mean to implement checked[/color][/color]
exceptions[color=blue]
> on[color=green]
> > the .NET platform. There are two ways you could do it.
> >
> > You could implement checked exceptions in C# only, but using libraries
> > written in other languages would be strange, in that they would not have
> > exception information. This probably would not work very well.
> >
> > The second option would be to implement checked exceptions throughout[/color]
> .NET.[color=green]
> > That would mean that all languages would be required to support checked
> > exceptions. I think it's fair to say that if Microsoft took that[/color][/color]
position,[color=blue][color=green]
> > it would not be a popular one amongst the language implementors, both[/color]
> inside[color=green]
> > and outside of Microsoft. We've tried to limit the requirements we[/color][/color]
impose[color=blue]
> on[color=green]
> > other languages as much as practical, and checked exceptions would be a[/color]
> bit[color=green]
> > imposition.
> >
> > Because of these considerations, checked exceptions are an issue where[/color][/color]
we[color=blue][color=green]
> > can't satisfy all of our users. We will continue to explore the issue in[/color]
> the[color=green]
> > future.
> >
> > --
> > Eric Gunnerson
> >
> > Visit the C# product team at http://www.csharp.net
> > Eric's blog is at http://blogs.gotdotnet.com/ericgu/
> >
> > This posting is provided "AS IS" with no warranties, and confers no[/color]
> rights.[color=green]
> > "OvErboRed" <overboredNO@SP AMoverbored.net > wrote in message
> > news:Xns93CB9B5 064749yangstaov erbored@207.46. 248.16...[color=darkred]
> > > I just read a whole bunch of threads on microsoft.publi c.dotnet.*[/color]
> > regarding[color=darkred]
> > > checked exceptions (the longest-running of which seems to be[/color][/color][/color]
<cJQQ9.4419[color=blue][color=green][color=darkred]
> > > $j94.834878@new s02.tsnz.net>.
> > >
> > > My personal belief is that checked exceptions should be required in[/color][/color]
> .NET.[color=green]
> > I[color=darkred]
> > > find that many others share the same views as I do. It is extremely
> > > frustrating to have to work around this with hacks like Abstract[/color][/color][/color]
ADO.NET[color=blue][color=green][color=darkred]
> > > and CLRxLint (which still don't solve the problem).
> > >
> > > On the other hand, it seems that most of the @microsoft.com posters[/color][/color][/color]
are[color=blue][color=green][color=darkred]
> > > ignoring or adamantly refusing to accept the argument (and fact) that
> > > exception specification is as essential as parameter and return type
> > > specification when it comes to creating well-defined interfaces.
> > >
> > > I'm wondering if there's any hope at all for MS to introduce checked
> > > exceptions into an upcoming iteration of .NET. What would it take to[/color][/color]
> move[color=green][color=darkred]
> > > MS to action (or at least more serious consideration) on such issues[/color][/color][/color]
as[color=blue][color=green][color=darkred]
> > > this? I realize that at this point, a shift at such a fundamental[/color][/color][/color]
level[color=blue][color=green][color=darkred]
> > > will not be easy, but perhaps this will be something to look forward[/color][/color][/color]
to[color=blue]
> in[color=green][color=darkred]
> > > .NET 2.[/color]
> >
> >[/color]
>
>[/color]

[OvErboRed]

Re: Checked Exceptions!

"Eric Gunnerson [MS]" <ericgu@online. microsoft.com> wrote in
news:OB3f9mjWDH A.3232@tk2msftn gp13.phx.gbl:
[color=blue]
> I think there are a couple of important considerations here.
>
> The first is whether checked exceptions are a good idea in principle.
> There are lots of different opinions here - some people think that
> checked exceptions are essential, some think that checked exceptions
> are good but should be used in conjunction with unchecked exceptions,
> and some think that checked exceptions cause more problems than they
> solve. For view against checked exceptions from the Java (and C++)
> world, I suggest looking at Bruce Eckel's position at
> http://www.mindview.net/Etc/Discussi...ckedExceptions.[/color]

You reference this paper frequently. Eckel's arguments are entirely
psychological. In fact, from a theoretical view, he readily concedes the
merits of checked exceptions. Rather, his points are based on the
developer's practical tendency to ignore exceptions in code that is
under construction.

Java provides you with an opt-out model:

....
} catch (SomeKindOfExce ption e) {}

From his perspective, this is bad, because it slows down lazy
programmers, or at least those "you might classify as beginners." That,
really, is the gist of his article.

I don't know about you, but frankly, I don't find this to be a very
sound argument for the exclusion of a feature that effectively *forces*
all developers to put up with a lax policy. In Java, less-scrupulous
programmers had the freedom to swallow exceptions or to add "throws
Exception" to their method signatures.
[color=blue]
> The second is what it would actually mean to implement checked
> exceptions on the .NET platform. There are two ways you could do it.
>
> You could implement checked exceptions in C# only, but using libraries
> written in other languages would be strange, in that they would not
> have exception information. This probably would not work very well.
>
> The second option would be to implement checked exceptions throughout
> .NET. That would mean that all languages would be required to support
> checked exceptions. I think it's fair to say that if Microsoft took
> that position, it would not be a popular one amongst the language
> implementors, both inside and outside of Microsoft. We've tried to
> limit the requirements we impose on other languages as much as
> practical, and checked exceptions would be a bit imposition.[/color]

I'm not entirely sure what you mean; I would think that the addition of
checked exceptions would hardly be any more significant a burden than
those already associated with reaching CLS compliance.

And even if such requirements demand extra effort of the language
implementors, the resulting benefits of static type checking would go a
long way in aiding the rest (the majority) of the .NET developer
community.
[color=blue]
> Because of these considerations, checked exceptions are an issue where
> we can't satisfy all of our users. We will continue to explore the
> issue in the future.[/color]

From your previous posts, I realize your concern with flexibility (e.g.,
the ability to throw SpecializedData baseException when connecting to a
DB), but this type of thinking is misguided. First of all, the issue is
already addressed in .NET with exception chaining/tunneling. Secondly,
if you seek true flexibility, there's always C/C++. C/C++, where
exceptions are thrown unchecked, pointers can reference any gosh-durned
location, and type casting knows no bounds.

But that sort of flexibility is not what .NET is about, is it? It's the
simplified abstractions and the higher level features of a clean, new
platform that attract programmers and make their lives easier. To omit
exception checking from this feature set is a critical mistake, and it
is unfortunate that Microsoft chose this path initially, but I implore
you to rectify the situation when the opportunity next presents itself.

[Frans Bouma]

Re: Checked Exceptions!

"Eric Gunnerson [MS]" <ericgu@online. microsoft.com> wrote in
news:#X751SsWDH A.656@tk2msftng p13.phx.gbl:
[color=blue]
> We are working to make the information about what exceptions could
> happen more available.
>
> In many cases, however, you can't derive it directly from code, because
> you're operating through interfaces, and you don't know at compile time
> what object is implementing them. Dynamic create of objects has the same
> problem, as does factory methods that return a base class.[/color]

While I think checked exceptions shouldn't be in a language
definition, to solve the problem you describe above, you could allow
exception definitions (if you go the checked exception route) in the
interface definition's method definitions, which then simply says: if
someone implements this method, it should throw this and this exception.

Which in itself is a reason not to use checked exceptions, because
what if the implementation of the method doesn't require to throw one or
two of these exceptions?

FB

--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------

[Jon Skeet]

Re: Checked Exceptions!

Frans Bouma <perseus.news@x s4all.nl> wrote:[color=blue]
> While I think checked exceptions shouldn't be in a language
> definition, to solve the problem you describe above, you could allow
> exception definitions (if you go the checked exception route) in the
> interface definition's method definitions, which then simply says: if
> someone implements this method, it should throw this and this exception.
>
> Which in itself is a reason not to use checked exceptions, because
> what if the implementation of the method doesn't require to throw one or
> two of these exceptions?[/color]

Then the implementation doesn't declare that it can throw the
exception, and if the caller *knows* which implementation is being used
(and has a reference of that type rather than just the interface type)
then they won't have to catch/pass on that exception.

For an example of this (in abstract classes rather than interfaces, but
it's the same principal) in Java, look at OutputStream.wr ite(int) and
PrintStream.wri te(int).

Basically an implementation/override can declare that it throws fewer
exceptions, but not more.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet/

If replying to the group, please do not mail me too

[Frans Bouma]

Re: Checked Exceptions!

Jon Skeet <skeet@pobox.co m> wrote in
news:MPG.199979 74ea8c50ed98a27 2@news.microsof t.com:
[color=blue]
> Frans Bouma <perseus.news@x s4all.nl> wrote:[color=green]
>> While I think checked exceptions shouldn't be in a language
>> definition, to solve the problem you describe above, you could allow
>> exception definitions (if you go the checked exception route) in the
>> interface definition's method definitions, which then simply says: if
>> someone implements this method, it should throw this and this
>> exception.
>>
>> Which in itself is a reason not to use checked exceptions,
>> because
>> what if the implementation of the method doesn't require to throw one
>> or two of these exceptions?[/color]
>
> Then the implementation doesn't declare that it can throw the
> exception, and if the caller *knows* which implementation is being used
> (and has a reference of that type rather than just the interface type)
> then they won't have to catch/pass on that exception.
>
> For an example of this (in abstract classes rather than interfaces, but
> it's the same principal) in Java, look at OutputStream.wr ite(int) and
> PrintStream.wri te(int).
>
> Basically an implementation/override can declare that it throws fewer
> exceptions, but not more.[/color]

Ok, but doesn't an interface implicate a fixed definition? So if an
implementator decides not to throw a given exception, does that
implementator in fact not implement the complete interface? It looks like
Sun cut a corner on this :)

FB



--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------

[Jon Skeet]

Re: Checked Exceptions!

Frans Bouma <perseus.news@x s4all.nl> wrote:[color=blue][color=green]
> > Basically an implementation/override can declare that it throws fewer
> > exceptions, but not more.[/color]
>
> Ok, but doesn't an interface implicate a fixed definition? So if an
> implementator decides not to throw a given exception, does that
> implementator in fact not implement the complete interface? It looks like
> Sun cut a corner on this :)[/color]

No, not at all. The interface says what you should do if a certain type
of thing does wrong. If that kind of thing can't possibly go wrong in
your implementation, then there's no need to redeclare that.

It's basically the Liskov Substitutabilit y Principle again - the
interface says, "If you've got something that implements this
interface, you can call this method and expect a certain result if a
certain thing goes wrong" - and the implementation where that certain
thing can't go wrong is still abiding by that interface.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet/

If replying to the group, please do not mail me too