Win a copy of Head First Agile this week in the Agile forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Bulky catch chain  RSS feed

 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I made several substantial changes to code loops as suggested by several authors, eliminating about 100 lines of code from main().

I quit chasing down all the re-codes in worker classes because a problem I knew would show-up sooner or later needs to be resolved to a solution approach before detailed recoding consumes several hours.

During prototyping, I want to use catches to provide one avenue of probing the actual workings of code - some complex interactions may result in a huge number of possible test cases. Whether prototyping or not, it has become apparent that the pattern of the catches in main()is the same, over a rather lengthy repetition. In C/C++ this would be handled with elipsis notation in the paramater list for the catch. I believe I tried this and got a compiler error.

The compiler seems to be efficient at telling me about throws and catches and so on, but I really need to factor out a rather bulky catch chain that differs only by the type of the exception caught, for the reasons cited by Stan James (instanceof Sidekick) and others.

I am posting to advanced because this is phase of code development that will set design patterns, therefore needs seasoned insight.
[ December 03, 2006: Message edited by: Nicholas Jordan ]
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Java, everything you can throw has a common supertype, "Throwable." Therefore the Java equivalent of "catch (...)" is "catch (Throwable t)". Of course, you virtually never want to go to that extreme. "catch (Exception e)" is far more common.

Note that catching, e.g., RuntimeExceptions is almost always wrong. The right thing to do is code so they don't appear. If you get them, then it's a coding error (most of the time, anyway); you don't want to hide them, but rather fix them.

Despite protestations to the contrary, this is a beginner topic. Off we go...
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
and where's the question?

I don't quite agree with Ernest about RuntimeExceptions though. There are situations in which particular RuntimeExceptions may have to be caught and can be handled (like when parsing user input, some parsers throw a RuntimeException on failure).
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Favor elegance over complexity.
 
Rahul Bhattacharjee
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:

Note that catching, e.g., RuntimeExceptions is almost always wrong.


In a general programs catching a runtime exception is wrong.But there are certain kind of applications and requirement where you have to catch a runtime exception.Suppose in case of a system integration tool , clients/agents talk to a system in xml and get xml responses.In that case we have to catch a runtime exception and send proper error code for that.
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or if you have a multithreaded system and you want a thread to never die.
You catch the RuntimeExceptions from the Runnable and try to recover from them.
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:
In Java, everything you can throw has a common supertype, "Throwable." Therefore the Java equivalent of "catch (...)" is "catch (Throwable t)". Of course, you virtually never want to go to that extreme. "catch (Exception e)" is far more common.

Note that catching, e.g., RuntimeExceptions is almost always wrong. The right thing to do is code so they don't appear. If you get them, then it's a coding error (most of the time, anyway); you don't want to hide them, but rather fix them.

Despite protestations to the contrary, this is a beginner topic. Off we go...



Dr. Friedman-Hill,

Thank you for your fast response.

In the 60 seconds it took me to logon, the thread is ballooning into the type of thread you recognize by "Off we go..." that is characteristic of my style, it is precisely because of letting seasoned professionals move this to beginner that tells me this is best approached by K.I.S.S. design methodology.

I definitely understand that right thing to do is code so they (RuntimeExceptions ) do not need to be handled. My design philosopy is to test to destruction during alpha, and I can now read the failure logs - BTW, the runlogs seemed not to be flushing.

At release, I will have to let ThreadInterrupted exceptions fail immediately due operational environment constrains. Managing a heavily threaded concurrency is remarkably difficult without a mathematica within reach of my skills that will do finite automa.

"catch (Throwable t)" provides me an outer loop construct with which I can continue design, letting ThreadInterrupted at critical design points be a different pattern, used appropriately with skill and dilligence.

Good design will virtually never want to go to the extreme of just exiting the entire JVM suddenly, it is a design operational constraint that gets into Threading.

See you soon, Dr. Wong !


[ December 04, 2006: Message edited by: Nicholas Jordan ]
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rahul Bhattacharjee:
In a general programs catching a runtime exception is wrong.But there are certain kind of applications and requirement where you have to catch a runtime exception.Suppose in case of a system integration tool , clients/agents talk to a system in xml and get xml responses.In that case we have to catch a runtime exception and send proper error code for that.


I notice that you are certified, I have been corrected by several persons on this - it is largely recurrent and lets see what you have to say.

For coding, compiling and testing, I proceed on the basis that if I make a coding error - the compiler will tell me about it or the runtime will fail. We can get into a lenghty disucssion about code-style, coding efficiency and correctness ..... it quickly splays out into a ThreadGill, as many threads as a fish has bony structures in the gills.

For all my effort, I am remarkably free of the type of failure others have pointed out to me. What I have decided is that if the *operator* of the program decides to quit early, that is an exceptional condition. I therefore use some type of ThreadInterrupted (lets reserve the semantices of that for the appropriate group) ~ this will act on a potentially large Thread Group.

The only thing we want to do if the operator decides to interrupt the program is interrupt the program. It is problem definition by operational constraints which define the operation of the program.

Comments ?
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!