This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Agile and Other Processes and the fly likes Clean Code - boilerplate code Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Clean Code - boilerplate code" Watch "Clean Code - boilerplate code" New topic
Author

Clean Code - boilerplate code

Radoslaw Zubek
Greenhorn

Joined: Sep 23, 2008
Posts: 1
I have problem with some way of encapsulating boilerplate code. To avoid writing some part of code for http requests and responses each time, I decided to encapsulate it in one method. This method gets only query string and listener for response.



My problem is, that I have to throw a various exceptions depends on 'status' variable and this exceptions are thrown through 'BaseException'.



My question is how to avoid this ugly code for casting exceptions and encapsulate some boilerplate code.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Unfortunately, I don't know of a good solution in Java.

If the number of possible exceptions is limited and small, you could use generics:



This is far from being an elegant solution, though, and becomes unwieldy once the number of exceptions grows or differs between implementations of the interface.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Paul Croarkin
Ranch Hand

Joined: Sep 30, 2004
Posts: 106
My approach to Exception handling is keep throwing until it can be handled. Most low-level exceptions cannot be handled directly by the code.

A good rule is to catch exceptions anytime an actor makes an action.

For instance, in a Web app where the user uploads a file path that does not exist, the proper thing is to tell the user that the file path does not exist. What value does the user get from the program catching some IOException (or worse swallowing it) way down in the code. They want to know what they did wrong or what the system did wrong and how to get around it.

A web service could be an actor and you may be expecting an XML file to come down the wire and it does not parse against the DTD or schema. Log it to an error file (or table) and possibly send an alert (email or page) to the production support team. Also be sure that the response you send back explains the error. Also make sure that you rollback any transactions.

[ September 23, 2008: Message edited by: Paul Croarkin ]
[ September 23, 2008: Message edited by: Paul Croarkin ]

Thanks,<br /> <br />Paul Croarkin<br />SCEA 5, SCWCD, SCJP
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Paul, I have no idea how your response addresses the original poster's problem...
Robert Martin
Author
Ranch Hand

Joined: Jul 02, 2003
Posts: 76
Originally posted by Radoslaw Zubek:
I have problem with some way of encapsulating boilerplate code. To avoid writing some part of code for http requests and responses each time, I decided to encapsulate it in one method. This method gets only query string and listener for response.



My problem is, that I have to throw a various exceptions depends on 'status' variable and this exceptions are thrown through 'BaseException'.



My question is how to avoid this ugly code for casting exceptions and encapsulate some boilerplate code.


Catch the exceptions by their true type!! Don't catch the base and then downcast. Yes, this means you'll have many catch clauses. That's better than having a set of instanceof statements...


---<br />Uncle Bob.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Robert Martin:

Catch the exceptions by their true type!! Don't catch the base and then downcast. Yes, this means you'll have many catch clauses. That's better than having a set of instanceof statements...


Mhh, yes... but - you will still have to catch BaseException, too, because that is what the interface declares. Of couse you know that it can't be thrown, but unfortunately, the compiler doesn't.

Mhh, just remembered that you prefer RuntimeExcptions. Problem solved.
[ September 25, 2008: Message edited by: Ilja Preuss ]
Robert Martin
Author
Ranch Hand

Joined: Jul 02, 2003
Posts: 76
Originally posted by Ilja Preuss:


Mhh, yes... but - you will still have to catch BaseException, too, because that is what the interface declares. Of couse you know that it can't be thrown, but unfortunately, the compiler doesn't.

Mhh, just remembered that you prefer RuntimeExcptions. Problem solved.

[ September 25, 2008: Message edited by: Ilja Preuss ]


The following code seems to work fine.

Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Robert Martin:

The following code seems to work fine.


Frankly, I think the third catch block is suboptimal. The only advantage checked exceptions have over non-checked exceptions is that the compiler will tell you if you are not handling them all. With the catch-all block, you loose that advantage - you won't be told automatically when there is a new Exception added that might need to be handled differently. And if you don't get that advantage, you might as well use non-checked exceptions to begin with (which I guess you would do ).
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Clean Code - boilerplate code
 
Similar Threads
exception handling
single return statement: yes / no?
Exceptions
Throwing exceptions... mock question doubt
Help me friends. I'll appreciate your answer.(Exceptions)