473,889 Members | 1,801 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Checked Exceptions!

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
$j*********@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.
Jul 19 '05 #1
26 2929
Fully agree to your views on checked exceptions. I program in Java also and
really appreciate this notion

"OvErboRed" <ov*********@SP AMoverbored.net > wrote in message
news:Xn******** *************** *******@207.46. 248.16...
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
$j*********@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.

Jul 19 '05 #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" <ov*********@SP AMoverbored.net > wrote in message
news:Xn******** *************** *******@207.46. 248.16...
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
$j*********@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.

Jul 19 '05 #3
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" <ov*********@SP AMoverbored.net > wrote in message
news:Xn******** *************** *******@207.46. 248.16...
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
$j*********@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.

Jul 19 '05 #4
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.
Jul 19 '05 #5
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" <ov*********@SP AMoverbored.net > wrote in message
news:Xn******** *************** *******@207.46. 248.16...
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
$j*********@n ews02.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
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.



Jul 19 '05 #6
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 :)
Jul 19 '05 #7
Andre <fo********@hot mail.com> 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 - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Jul 19 '05 #8
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]" <er****@online. microsoft.com> wrote in message
news:OB******** ******@tk2msftn gp13.phx.gbl...
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" <ov*********@SP AMoverbored.net > wrote in message
news:Xn******** *************** *******@207.46. 248.16...
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
$j*********@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.


Jul 19 '05 #9
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" <kd******@wi.rr .com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
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]" <er****@online. microsoft.com> wrote in message
news:OB******** ******@tk2msftn gp13.phx.gbl...
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" <ov*********@SP AMoverbored.net > wrote in message
news:Xn******** *************** *******@207.46. 248.16...
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 $j*********@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.



Jul 19 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
2700
by: Hung Jung Lu | last post by:
Hi, Just ran into this article http://www.mindview.net/Etc/Discussions/CheckedExceptions And I felt kind of reliefed. When I programmed in Java I always thought its usage of "checked exceptions" was kind of... silly. "Checked exceptions" are Non-RuntimeException exceptions, your method declaration must specify them, and also you need to catch them or
33
3402
by: OvErboRed | last post by:
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 $j94.834878@news02.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...
9
1471
by: F. GEIGER | last post by:
Hi everybody, I like checked exceptions as provided by Java. No, I don't want to start a thread on that, but ask, if anyone knows of a tool for that. It may be stand-alone, but being plugable into MSVS would ease its use, I guess. Many thanks in advance and best regards Franz GEIGER
9
1875
by: Jeff Louie | last post by:
I drank too much coffee last night and came up with a suggestion about how to add checked exceptions to C# http://www.geocities.com/jeff_louie/OOP/oop14.htm Comments expected <g> Regards, Jeff
0
9810
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11199
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10442
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9610
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7997
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7150
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5830
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
2
4251
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3256
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.