I just read a whole bunch of threads on microsoft.public.dotnet.* regarding
checked exceptions (the longest-running of which seems to be <cJQQ9.4419
$(E-Mail Removed)>.

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.

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

"OvErboRed" <(E-Mail Removed)> wrote in message
news:Xns93CB9B5064749yangstaoverbored@207.46.248.16...
> I just read a whole bunch of threads on microsoft.public.dotnet.*
regarding
> checked exceptions (the longest-running of which seems to be <cJQQ9.4419
> $(E-Mail Removed)>.
>
> 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.

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

"OvErboRed" <(E-Mail Removed)> wrote in message
news:Xns93CB9B5064749yangstaoverbored@207.46.248.16...
> I just read a whole bunch of threads on microsoft.public.dotnet.*
regarding
> checked exceptions (the longest-running of which seems to be <cJQQ9.4419
> $(E-Mail Removed)>.
>
> 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.

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" <(E-Mail Removed)> wrote in message
news:Xns93CB9B5064749yangstaoverbored@207.46.248.16...
> I just read a whole bunch of threads on microsoft.public.dotnet.*
regarding
> checked exceptions (the longest-running of which seems to be <cJQQ9.4419
> $(E-Mail Removed)>.
>
> 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.

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.

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

-Andre

Kieran Benton wrote:
> 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" <(E-Mail Removed)> wrote in message
> news:Xns93CB9B5064749yangstaoverbored@207.46.248.16...
>
>>I just read a whole bunch of threads on microsoft.public.dotnet.*
>
> regarding
>
>>checked exceptions (the longest-running of which seems to be <cJQQ9.4419
>>$(E-Mail Removed)>.
>>
>>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.
>
>
>

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

Andre <(E-Mail Removed)> wrote:
> Another issue is the runtime performance cost involved with checked
> exceptions.

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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

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]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>
> 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.
>
> 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.
>
> --
> 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.
> "OvErboRed" <(E-Mail Removed)> wrote in message
> news:Xns93CB9B5064749yangstaoverbored@207.46.248.16...
> > I just read a whole bunch of threads on microsoft.public.dotnet.*
> regarding
> > checked exceptions (the longest-running of which seems to be <cJQQ9.4419
> > $(E-Mail Removed)>.
> >
> > 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.
>
>

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" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > --
> > 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.
> > "OvErboRed" <(E-Mail Removed)> wrote in message
> > news:Xns93CB9B5064749yangstaoverbored@207.46.248.16...
> > > I just read a whole bunch of threads on microsoft.public.dotnet.*
> > regarding
> > > checked exceptions (the longest-running of which seems to be
<cJQQ9.4419
> > > $(E-Mail Removed)>.
> > >
> > > 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.
> >
> >
>
>