Article Discussion
Analyze this!
Summary: James Gosling talks with Bill Venners about his current research project, code-named Jackpot, which builds annotated parse trees for programs and can help you analyze, visualize, and refactor your program.
19 posts on 2 pages.      
« Previous 1 2 Next »
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: July 31, 2019 2:55 AM by guy
Mark
Posts: 4 / Nickname: markm / Registered: November 13, 2003 6:14 PM
Re: Analyze this!
November 14, 2003 0:11 AM      
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
Posts: 4 / Nickname: markm / Registered: November 13, 2003 6:14 PM
Re: Analyze this!
November 14, 2003 0:33 AM      
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
Posts: 62 / Nickname: matt / Registered: February 6, 2002 7:27 AM
Re: Analyze this!
November 14, 2003 11:28 AM      
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!).
guy
Posts: 1 / Nickname: booms1 / Registered: July 31, 2019 2:44 AM
Re: Analyze this!
July 31, 2019 2:55 AM      
Yes,that's very interesting stuff to know about. Thank you so much for the valuable information.
19 posts on 2 pages.
« Previous 1 2 Next »