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]

[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]

[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]

[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.

[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]

[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 :)

[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

[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