Win a copy of Zero to AI - A non-technical, hype-free guide to prospering in the AI era this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

Clean Code - boilerplate code

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul, I have no idea how your response addresses the original poster's problem...
 
Author
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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...
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 ).
 
Get me the mayor's office! I need to tell her about this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic