The Artima Developer Community
Sponsored Link

News & Ideas Forum (Closed for new topic posts)
Analyze this!

17 replies on 2 pages. Most recent reply: Nov 14, 2003 2:28 PM by Matt Gerrans

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 17 replies on 2 pages [ « | 1 2 ]
Mark McConkey

Posts: 6
Nickname: markm
Registered: Nov, 2003

Re: Analyze this! Posted: Nov 14, 2003 3:11 AM
Reply to this message Reply
Advertisement
I programmed in C/C++ for about 10 years prior to using Java and not having a reminder to catch an exception is a significant problem. I aplaud James for attempting to correct this problem. It is fairly obvious that interface issues can be solved by nesting exceptions or even converting them to runtime exceptions. I believe the only major issue with checked exceptions that cannot be overcome fairly easily is the empty catch clause. I actually feel that James would be doing himself more justice to acknowledge this as a real world problem as opposed to seemingly implying that the education system is at fault. Often times contractors are hired by companies to do short term work under tremendous time pressures. This is going to happen whether or not our education system encourages it due to haste and or laziness. I know that for myself the empty catch clause is not much of a problem because I and my close colleagues do not use empty catch clauses without much scrutinization of the situation at hand. Checked exceptions have VASTLY improved error checking in my programs.

I have a partial workaround and a proposed solution. Unfortunately the solution would not be backwards compatible.

The workaround is to search inherited source for empty catch clauses and DO SOMETHING ABOUT THEM! You have bugs in your source if error checking isn't being handled! Of course this would not work if you purchased a third party library for which you do not have the source.

The proposed solution would be to have the empty catch clause convert all exceptions it catches into runtime exceptions and rethrow them i.e. the exact behavior you would have had without the checked exceptions in place. Yes this allows sloppy or lazy programmers to circumvent the checked exceptions mechanism but it allows meticulous programmers to still use checked exceptions and it eliminates the possibility of the horrendous down stream bugs that can be caused by an empty catch clause and which should be acknowledged by the creators of the checked exception mechanism. If one truly wants and needs an explicit empty catch clause that does nothing a keyword could be added to the language such as explicitempty.

catch( IOException ex ){
explicitempty;
}

The truly lazy programmer will not go to the effort of typing in "explicitempty;" especially if the recommended behavior is to leave the clause empty.

Mark McConkey

Posts: 6
Nickname: markm
Registered: Nov, 2003

Re: Analyze this! Posted: Nov 14, 2003 3:33 AM
Reply to this message Reply
I programmed in C/C++ for about 10 years prior to using Java, and not having a reminder to catch an exception is a significant problem. I aplaud James for attempting to correct this problem. It is fairly obvious that interface issues can be solved by nesting exceptions or even converting them to runtime exceptions. I believe the only major issue with checked exceptions that cannot be overcome fairly easily is the empty catch clause. I actually feel that James would be doing himself more justice to acknowledge this as a real world problem as opposed to seemingly implying that the education system is at fault. Often times contractors are hired by companies to do short term work under tremendous time pressures. This is going to happen whether or not our education system encourages it, due to haste and or laziness. I know that for myself the empty catch clause is not a problem because I and my close colleagues do not use empty catch clauses without a great deal of scrutinization of the situation at hand. Checked exceptions have VASTLY improved error checking in my programs.


I have a partial workaround and a proposed solution for those who are having problems. Unfortunately the solution would not be backwards compatible.


The workaround is to search inherited source for empty catch clauses and DO SOMETHING ABOUT THEM! You have bugs in your source if error checking isn't being handled! Of course this would not work if you purchased a third party library for which you do not have the source.


The proposed solution would be to have the empty catch clause convert all exceptions it catches into runtime exceptions and rethrow them i.e. the exact behavior you would have had without the checked exceptions in place. Yes this allows sloppy or lazy programmers to circumvent the checked exceptions mechanism but they are doing this already with far worse consequences. In addition, it allows meticulous programmers to still use checked exceptions and it eliminates the possibility of the horrendous down stream bugs that can be caused by an empty catch clause, the same bugs which should be acknowledged by the creators of the checked exception mechanism as highly problematic. If one truly wanted and needed an explicit empty catch clause that did nothing, a keyword could be added to the language such as explicitempty.


catch( IOException ex ){
explicitempty;
}


The truly lazy programmer will not go to the effort of typing in "explicitempty;" especially if the recommended behavior is to leave the clause empty.

In short, for those who are already not using the checked exceptions mechanism, the behavior would default back to that of not having checked exceptions. However, the programmer would have to consiously acknowledge the exception even if they only choose to convert it into a runtime exception.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Analyze this! Posted: Nov 14, 2003 2:28 PM
Reply to this message Reply
Just a critique of the clich├ęs:

> "Old wine in new bottle"

Hmm... is that a bad thing?

> "Reinventing the wheel"

Ever looked around the parking lot? Five bucks says you won't see two identical wheels that are not on the same car (or an identical car!).

Flat View: This topic has 17 replies on 2 pages [ « | 1  2 ]
Topic: Standards and Innovation Previous Topic   Next Topic Topic: Failure and Exceptions


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us