Easymock before

Around 2005 there were several mocking frameworks available. The main reason I chose to work with easymock was that it was both powerful and refactoring friendly. It supports automatic safe refactorings well because the expectations on method calls aren’t setup as a loose string-snippet but on statically typed info (method call expectations are directly bound to the object-type).

Though I found easymock great and made stubbing and mocking much easier as before, I found it had some drawbacks (speaking of version 2.5):

• The mocking/stubbing of interfaces vs. classes is not transparent. It is done through different Main-classes (EasyMock + classextension.EasyMock). This implied that mixing mocking both interfaces and classes inside one test-class followed in cluttered code and importing hell.
• The error messages of easymock are confusing sometimes. Often it is not clear whether the test-case has failed or easymock was used wrong (e.g. forgetting to call replay()).
• The mandatory call of replay() after having setup the mocked object always felt redundant and made test-case longer.
• The non-clear separation between setting up a mock and verifying it. Setting up a mock added also a verification on all expectations as soon as you called verify(). When writing + reading test-code this always confused me, because you already had to cope with verify logic in the setup part of the test-case.

Mockito after

The guys of Mockito say that they were inspired by Easymock and indeed you see its heritage. After having used it for about 3 months now so far the hands-on impressions are great and I now exclusively use Mockito for writing unit-tests.

My positive experiences were:

• Test-code still is safe in regard of using static-typed based automatic refactorings.
• Transparency of classes vs. interfaces. In both cases you call Mockito.mock(MyInterface.class) or Mockito.mock(MyClass.class).
• Clear seperation between setting up a mock and verifiying it. This feels more intuitive and the clear setup/excercise/verify test-code order is preserved.
• Helpful error message, when an assertion wasn’t met or the tool guessed a framework usage error.
• The naming of methods is intuitive (like when(), thenReturn()).
• When earlier I used the real domain-objects as test-data (i.e. by filling data through setters/constructors), now I use mockito to stub them (i.e. stubbing the getters). Domain code logic has now much less impact on test-runs.
• Nice short, straightforward documentation.
• A great name + logo ;)

In summary: The mockito folks did a great job (they took the nice ideas from Easymock creator and improved its drawbacks). Now looking at old test-code using Easymock I subjectively need much more time to grasp what the intent of the test is. With Mockito the test-cases read more like a clear sequential “requirements story” like test-cases always should.

Migration of test-code

If you are already using easymock the tool switch is amazingly quick. Following migration path helped me:

1. Give yourself and your colleagues around two weeks investing time to work with the tool and get comfortable with it. Write all your new test-classes with Mockito.
2. If you like it make the switch: Explicitly communicate that using the old mocking framework is deprecated (if possible use static code analysis tools where you can mark severaly packages deprecated (org.easymock.*)). Now usage of Mockito for new test-classes should be mandatory.
3. If you have already big test-codebase I do NOT recommend a big-bang test-code migration. Such migration work is time consuming and boring. Therefore taking the incremental approach is better: Only migrate Easymock code to Mockito in case you anyway touch the class, i.e. are modifying or adding test-cases.

Looking at the test-migrations I did so far, migrating Easymock code to Mockito is quite straightforward. Get rid of all replay(), verify() calls and adjust to the slight API changes. The only thing you have to watch out for more are the explicit verification on mocked-calls. Easymock did implicitly verify all expectations when calling verify() on the mock-object, on Mockito side you explicitly have to call verifications on each method. The same counts for strict mocks. You have to add respective verifications.

Note: For simplicty throughout the post I will use java terms (class, method, package). Of course this can be mapped to other languages constructs like functions, file-includes or plain-script statements.

Advantage of more fine grained modularization:

• Maintaining less artifacts (e.g. files, packages, libraries) makes the build/deployment-lifecyle easier.
• For simple features code browsing gets easier (“You see all stuff with one eye-sight”)

The drawback is that the fine grained approach doesn’t scale: The bigger the codebase gets the more difficult it is to “see” any modularization or separatation of concerns. The coarse grained modularization gives you advantage here:

• Bigger systems are easier to comprehend if the “split” is done on package or library level.
• Refactorings are getting easier because inside the modules the direct numbers of dependencies get less (submodules only import dependencies they need).
• Unit-test setup gets easier (for reason see Refactoring)

Where to start?

The question is at which modularization level you should start. There are two major antipatterns, either developers sticked on too fine level (e.g. 6000 LOC inside one single file) or they started on a too coarse level (e.g. each of the many packages only contains one or two classes). The too coarse pattern often occurs if you overengineer solution.

Code from scratch

To avoid the too fine/coarse pitfall I follow the Inside-Out modularization approach:

1. Start to edit a single file. Implement the highest priority requirements of feature inside the most fine grained “module” your language can you offer (e.g. class-method).
2. When code inside a method gets bigger and you lose overview try to cluster statements (e.g. by speparating them with line-breaks).
3. When code statement clusters get too many and you see duplications, extract these section to a new method.
4. When there are too many methods and the lines of code inside the single file are very high, cluster your methods by problem domain and extract them to a new class in the same package.
5. When there are too many classes inside on package, either create a subpackage or sibling-package which fit to the problem domain (separation of concerns).
6. When a package hierachy/tree gets too deep and wide, create a new package hierachy (e.g. com.foo becomes com.foo.system1 and com.foo.system2)
7. When there are too many package hierachies inside one library (like .jar), create another library-project (e.g. Maven project/module).

Integrate changes in existing code

Above is a more or less complete list when starting with code from scratch. But how does it apply to existing code and integrating changes? The main principle is the same but you would start your Inside-Out modularization on a different level. As Example: If you have to add code inside a class and see it you feature-adding would result in too many methods you start off with step number four (extracting class).

At which step to level up?

It is always the question, when to level up from a fine to a more coarse grained modularization. It is very difficult to have a thumb of a rule, because this highly matters on code-style taste, on density of ‘if/else’ logic and also on the problem-domain you are trying to solve. A very good test is either ask colleagues for review whether the modularization is intuitive or take another look the next day or a week after to get a fresh view.

The following codebase size and LOC metric scope is not fine grained on function or class level but for complete codebase or at least on subcomponent level.

Bad (anti-pattern): Codebase size as progress metric

Sometimes (though fortunately rarely) QA or project management is taking codebase size and LOC as a progress metric to see what the project’s state is. The more lines of code have been written the closer the project is seen to have been completed. This is a definite anti-pattern for following reasons:

• It is extremely difficult to estimate, how much code will be necessary for a certain scope or a set of requirements. This implies that project or product management cannot know, how much code is missing to mark the requirements as done.
• It is more about quality as of quantity of code. Well structured code with avoidance of duplication tends to have less lines of code.
• It is very important and valuable to throw away dead code (code which isn’t used or executed anywhere). Using lines of code as a progress metric would mean this important refactoring will cause a negative project progress.

Good: Codebase size as compexity metric

With a higher LOC metric you are likely to face following problems:

• Increase of feeback time: It takes longer to build deployable artifacts, to startup application and to verify implementation behaviour (this both applies to local development and CI servers).
• Tougher requirements on development tools: Working on large codebases makes the IDE often run less smoothly (e.g. while doing refactorings, using several debugging techniques).
• Code comprehension: More time has to be spent for reverse engineering or reading/understanding documentation. Code comprehension is vital to integrate changes and debugging.
• More complex test-setup: Bigger codebases tend to have more complicated test-setup. This includes setting up external components (like databases, containers, message-queues) and also defining test-data (the domain model is likely to be rich).
• Fixing bugs: First of all exposing a bug is harder (see test-setup). Further more localization of bug is tougher, because more code has to be narrowed down. Potentially more theories exist to have causes the bug.
• Breaking code: New requirements are more difficult to implement and integrate without breaking existing functionality.
• Product knowledge leakage: Bigger codebases tend to cover more functionality. The danger increases, that at some point the organization loses knowledge which functionality the software supports. This blindness has very bad implications on defining further requirements or strategies.
• Compatibility efforts: The larger a codebase the more likely it is that it already has a long lifetime (codebases tend to grow over the years). Along the age of software down-compatibility is a constant requirement, which increases (a lot of) effort.
• Team size + fluctuation: Bigger codebases tend to have been touched by a big size of developers, which can cause knowledge leakage. Due to communication complexity, each developer only knows just a little part of the system and does not distribute it. Even worse due to team-size fluctuation is likely to be higher and knowledge gets completely lost for company.
• etc. …

Quantification of LOC impact is hard

Above statements are more qualitative and are not quantifiyable, because the exact mapping of a certain LOC number to a magic complexity number is unfeasible. For instance there are other criterias which have an impact on the complexity of a software system, which are independent of LOC:

• Choice of programming language/system: Maintaining 1.000 LOC of assembly is a complete different story as doing it with 1.000 of Java code.
• Problem domain: Complex algorithms (e.g. to be found in AI or image processing) tend to have less lines of code but still are complicated.
• Heterogenity of chosen technology in your complete source-code ecosystem: E.g. using 10 different frameworks and/or programming-languages and making them integrate to the overall system harder as concentrating on one framework.
• Quality and existence of documentation: E.g. Api-interfaces aren’t documented or motivations for major design decision are unknown. From developers point of view such a system is effectively more complex because a lot of effort has to be spent in reverse engineering.
• etc. …

Conclusion

The metric LOC representing codebase size has a big impact on your whole software development cycle. Therefore it should be measured, observed and tracked over time (also by subcomponent). Apart from showing you the current state and evolution of your codebase from historical point of view you can also use it proactively for future:

• Estimation/planning: When estimating features take the LOC metric has influence criteria. The higher the LOC the more complicated it will be to integrate feature.
• YAGNI: Take YAGNI (“you ain’t gonna need it”) principle to the extreme. Only implement really necessary features. Do not make your software over-extensible and as simple as possible.
• Refactor out dead code: Being aware of LOC as a complexity metric, you can create a culture of dead-code awareness. Throw away as much unused code away as you can.
• Refactor out dead functionality: Software products often are unneccessarily overcomplex. Also push business towards are more simple product strategy and throw away unused features and achieve a smaller codebase.

JDBC Driver to classpath

Tomcat realm handling is container internal, therefore it is not enough to have jdbc-driver (e.g. mysql-connector-java-5.1.6.jar) in your application classpath. You have to explicit add it to the container classpath (e.g. TOMCAT_HOME/lib).

Configuration Snippets

Tomcat container config, which can appear as nested element inside <Engine>, <Host> or <Context> (e.g. TOMCAT_HOME/conf/context.xml):

...
<!-- database connection settings + enabling hashed passwords (MD5 sum style) -->
<Realm
 className="org.apache.catalina.realm.JDBCRealm"
 digest="MD5"
 driverName="com.mysql.jdbc.Driver"
 connectionURL="jdbcURL"
 connectionName="dbUser"
 connectionPassword="dbPwd"
 userRoleTable="role_table"
 userTable="user_table"
 userNameCol="dbuser_column"
 userCredCol="dbpwd_column"
 roleNameCol="role_column"/>
...

Webapplication web.xml:

<web-app>
...
 <security-constraint>
   <web-resource-collection>
     <web-resource-name>Secure area</web-resource-name>
     <url-pattern>/*</url-pattern>
   </web-resource-collection>
   <auth-constraint>
     <role-name>admin</role-name>
   </auth-constraint>
 </security-constraint>

 <login-config>
   <!-- enabling HTTP Auth digest mode -->
   <auth-method>DIGEST</auth-method>
   <realm-name>your-realm</realm-name>
 </login-config>

 <!-- roles must be defined to be used in security-constraint -->
 <security-role>
   <description>Role sample</description>
   <role-name>admin</role-name>
 </security-role>
...
</web-app>

Password patterns

For HTTP Auth Digest tomcat expects a special cleartext pattern for the hashed password entry inside the database. Unfortunately the cleartext snippet is different from the one from Http Auth Basic (this took me some time to find out…).

Bash CLI samples for HTTP Auth password hashing (md5sum):

# Basic style (only the password without user or realm info is hashed)
echo -n password | md5sum
# Digest style ('your-realm' is entry from web.xml->login-config->realm-name)
echo -n username:your-realm:password | md5sum

Migration HTTP Auth Basic to Digest

As you saw above tomcats Auth Basic and Digest cleartext password patterns are different. Therefore just switching the entry of web.xml->login-config->auth-method from ‘BASIC’ to ‘DIGEST’ wouldn’t suffice. I recommend to completely create a new database column (e.g. passwords_digest) so the separation and transition-path between Basic and Digest style is more clear. In case you hashed the Basic passwords already further more you have to reset the user passwords (the nature of good hashes are that you practically cannot map back to cleartext).

IDE defaults

Defaults from several IDEs or more simple text-editors are already giving big help, e.g. in showing keywords, instance fields or comments. Still in my view they can be tweaked, most of editors give options to extend things. Either they work with a graphical interface for changing settings (IDEs like IntelliJ, Eclipse etc.) or are working themselves with plain text highlighting configuration files (vim, krusader etc.). Your syntax highlighting toolbox contains text-decorations (like italic, underscored, bold) and coloring (foreground, background).
For my tweaks I used my favorite IDE IntelliJ, which offers many syntax highlighting options. Just checkout your editor and see what is possible.

Example BEFORE

Following annoyed me on the default settings:

• Could not instantly see parameters and variables
• No difference between local-vars and parameters
• Non-javadoc comments were too grey. I write comments to explain the ‘Why’ or a important block of a code statement. So comments should be better visible.
• Todo comments were blue. Blue is a too “friendly” color to me, whereas looking at todos should wake me up!
• Instance and static vars were colored the same though they have different semantics.
• I tend to use more smaller methods as one monster method. The default highlighting does not separate between method declarations and calls.

The BEFORE snippet:

Example AFTER

I changed settings to:

• Non-instance + static variables are blue now. Parameters should be handled with more care. (changing them side-effect the callee), so they are bold.
• Static and instance vars have different colors now (pink vs. violet).
• Comments have slight green background now.
• Todo flags have the signal-color orange
• Methods are underscored. Declarations are bold, calls are non-bold.

The AFTER snippet:

Vimperator

Vimperator is a real gem! Adds some vim (editor) feeling to the browser. Makes you faster, because nearly all mouse action can be supplemented with keyboard shortcuts. Also automates more complicated flows with macros. At start using vimperator can be somewhat annoying because pressing some keys do unexpected things, but investing time to get used to it pays off definetely.

Xmarks

Xmarks saves your bookmarks to a server and makes synchronization possible between different machines. Very handy if you are working from different computers. Most likely it could be replaced by upcoming firefox 4 which offers this functionality in its core.

Web Developer

Web Developer is a nice webdeveloper testing kit. Numerous things can be done like style/CSS testing, gathering meta-information of the page, handling cookies, finding broken images.

Firebug

Firebug is a perfect accompany to Webdeveloper for testing/analyzing websites. Offers JavaScript debugging, analyzing DOM tree, viewing CSS styleor watching HTTP calls and request/response contents. It is also plugin aware (see below).

Firecookie

Firecookie is an addon for firebug. Makes cookies handling (reading, deleting, editing) much easier as with Webdeveloper plugin.

YSlow

YSlow is an addon for firebug, which offers performance test for webapplications. Gives a good overview how your site performs and gives a summary in grade style (A-F). If it gives you bad grade, still question whether they are appropriate in your special case (e.g. YSlow moans about missing CDNs, but an usage of a CDN doesn’t always makes sense or you don’t have any control over certain included components).

Live HTTP Headers

Firebug offers good HTTP traffic tracking. But sometimes I also use Live HTTP Headers because you can filter tracking HTTP calls by URL and content-type, for HTTP POST you can set your own defined payload.

JSONView

When testing webapps, instead of using curl sometimes it is handy to fire a HTTP request directly through firefox. If doing so by default firefox makes problems and prompts to save json (Content-type: application/json) as a file to instead of just displaying the content inside the browser window. JSONView bypasses this and displays json content appropriately.

Let’s look at a very simple example. When trying to test an exception with JUnit 4 with different test-data I would need to write something like:

This code has essential problems:

1. Because I want to avoid to write two more test-methods (essentialy the same production code is triggered), I am putting three test-cases into one test-method, which is bad practice. This is because test cases aren’t using the tearDown and setUp facilities and cannot guarantee isolation. That is also the reason that I could not use the excpectedException parameter inside the JUnit 4 @Test annotation. Alternative is to really use three test-methods, but code readability then suffers.
2. Even though above example is very simplified (only new Foo() is called) the test-code is not expressive. Surely you could improve this by extracting method and giving a good name. But still it is a bit blurry, why we do so and that it is just for using different test-data.

TestNG parameterized test-methods

TestNG does it better and builds the “test-case differs only in test-data” situation into its framework. This is done by building a DataProvider and passing parameters to the test-method. This way code gets more expressive and each different test-data set is executed as an isolated test-case also. Here an example of the TestNG version of above test-cases (I followed the code centric way, you can also configure your DataProvider through an XML file):

No atomic commits

Once you checked in files it is very hard to revert to a certain state, because atomic commits aren’t supported. When checking in multiple files, each file gets a new revision (similar to CVS) and not the check-in itself. I think this is a crucial feature, because you hardly want revert single files but complete commit actions (which should map tasks). With ClearCase you can only revert to certain states by using Labels. In practice using ClearCase Labels for each check-in is overkill and thus not done.

Crappy user interface

The GUI of ClearCase Explorer is just a big joke. Horrible in usability and ugly looking. Different and often necessary functions aren’t provided (e.g. recursively checking in worked on artifacts). Command line tool cleartool used with cygwin is much better, but still some things aren’t available like recursively adding new files/folders to source control. I have to laugh my head off if I read a 50 lines of code long script to workaround this.

High administration efforts

Administrating ClearCase beast is far from obvious or lightweight (in difference to other scm-systems like CVS, subversion or Git). Expect to put quite a few dedicated ClearCase experts to just keep it running.

Horrible performance

Nothing is worse as making your developers wait while interfacing with SCM-tool, it is like driving with hand brakes enabled. It slows down your brain and also your work. Getting fresh new files to your snapshot view takes around 30 minutes for 10K artifacts. An update (no artifacts were changed) for the same amount takes roughly 5 minutes. When experimenting a lot and jumping between different up-to-date views means a lot of waiting. It gets even worse, when you’re working on files and you want to check-in or update them. Check-out, check-in and adding to source control cycles take around 10-15 seconds which is obviously a nightmare. It gets very annoying when you’re refactoring renaming/moving types or methods (many files can be affected).

Lack of support of distributed development

Today software development is often a distributed thing (developers are spread around the world working on the same product/project). ClearCase definetely isn’t suitable for this, because it is badly suited for offline work. Doing a check-out (action before you can edit a file/folder) requires that you are network connected. Here you could use the hijack option but this is rather a workaround as a feature (you basically just unlock the file on the filesystem). If your development sites are far away from your ClearCase server the check-in/check-out latency can even increase so dramatically that it is not usable at all. There are workarounds for that like using ClearCase Multisite (scm DB replica technology), but you have to pay extra for it and is not trivial to adminstrate.

Git as alternative

Though being a big fan+supporter of Open Source I am still willing to pay money for good software. But looking at IBM-monster ClearCase I wouldn’t invest my money here, it has all these discussed shortcomings, and further more IBM doesn’t seem to invest money to improve their product significantly. Recently I had a look a Git scm which looks very good, especially for its branching+merging features, where ClearCase has its major strengths.

Code quality issue

Code gets written and as it changes (in most cases) it rottens also. In many projects/products changing and adding functionality means having a larger codebase. And the bigger it gets the more difficult it becomes to improve the overall code quality picture:

• Motivation of developers decreases to keep code clean. In the end code gets worse and worse, just have a look
  at the ‘Broken windows’ chapter of ‘The Pragmatic Programmer’ for details
• Efforts to clean up increases, more code needs to be maintained. Even if we are highly motivated to write ‘good’ code, it is often difficult to know where to start.

Solution: Improve what you change

There are two ways to tackle the problem: Big Bang or continous code improval. With BigBang you dedicate armies of developers who touch code just for the sake of making the code ‘better’. This approach has its drawbacks: You still don’t know where to start, it is difficult to sell to the product owners (feature stop) and further more it gets really boring (ever tried to tidy up your flat for a whole week without doing anything else?). An approach which worked better for team members and me was to introduce a kind of continous code improvement. It is important not to say that we get from 10000 warnings to 0, but to make a commitment that the warnings never ever get higher and must decrease after constantly. Here you improve your code quality in parallel to feature development and you only improve what you change. This much better sells to the product owner, you even don’t need to mention it, because it is part of your daily effort and should be transparent for non-techies.
Furhter more incremental work-items can be managed better and focusing on certain artifacts also reduces overall efforts. In my view the best “quality-gate” for such an improve-what-you-change workflow is the source control commit or checkin phase. You changed code and now you want to ensure that checked-in sources provide a certain code-quality level.

Source control dialog IntelliJ:

IntelliJ approach to continous code quality improvement

The real problem is the tooling support: Humans are very bad at automating repeatable tasks. For instance when I am using Eclipse IDE and commiting sources to for instance Subversion, I often forget to reformat source code, remove unused imports or am just overlooking bad code snippets. IntelliJ (tested on version 8.1) goes a much better way: It provides actions (auto-formatting, auto-importing) while commiting and besides that can run static code analysis. For this code analysis it includes the so called ‘Inspections’, which are numerous and sensible (). For some cases it even provides an automated correction of the code flaw and the corresponding code snippet (pressing Alt+Enter). All these actions and checks are performed for the items you are about to commit only. This way IntelliJ mandates the successful approach to improve what you change or touch.

Dialog to review inspections and inspection results after pressing ‘Review button’ :

This topic was already discussed by clever Bruce Eckel, who is also thinking that checked exceptions aren’t such a good idea. To his reasoning one thing I would like to add is the “blurry assumption of api-interface” problem.

Anticipation of incoming dependencies not possible

Officially Sun mentions that checked exceptions should be used in case of “expected” exceptions, where clients still could react. In contrast unchecked exception should be used if programming erros occur, where a reaction is hardly possible (e.g. NullPointerException, AssertionError).

In case of checked exception client code can decide whether to react to it directly (try/catch) or to delegate and pass it in the throws clause. In practice many checked exceptions aren’t interesting to client code, therefore you start to pass it to the throws clause. After a while spreading exceptions between different class-collaborations they are getting piled up and code-distraction is king and developers are constantly typing irrelevant code.

I’ve often seen code where developers got fed up with this pass-through of exceptions, workarounded this with a bad exception handling coding style. So, in theory checked exceptions should increase code quality but in practice I perceived the opposite. This is bad, because a programming language design should help you to write good code and not constrain your work. Following workaround code snippets are quite common:

Above is evil: Though exception should somehow be reported in lower area of method call stack, this try/catch just makes any error handling impossible. Such “nirvana” exceptions can make your life really hard when locating defects.

Problem is that above newly thrown RuntimeException is too general and analyzation of certain error-conditions is hard. Often the causing checked exception isn’t even passed to the RuntimeException constructor so finding the root cause of a failure is also difficult.

To summarize: If client code cannot handle the exception, in practice checked exceptions aren’t passed to throws clause of method declaration. Indeed you can get really crazy if you need to pass the exception the whole method call-stack. Especially when doing bigger refactorings such millions of checked exceptions in the throws declarations are extremely annoying. Looking at this shortcoming developers often go for an improper exception handling. The difficulty of api-designers is that they cannot anticipate the exception-interpretation of incoming dependencies and thus the use of a checked exception can lead to bad exception handling code. They just don’t know, if a handling of an exception makes sense or not, see following examples:

Example checked IOException

Trigger: IOException from java.io api gets thrown because a file under given pathname cannot be found.
Handling appropriate: My client-code represents a file system manager, where I am searching for a file. The information “File not found” is directly relevant and file system manager could proceed to look in other directories.
Handling not appropriate: I got a general app, where a property file should be loaded. Then the app should crash early/instantly, most likely I set a wrong path (Programming error).

Example checked RemoteException

Trigger: RemoteException gets thrown, because network connection for RMI communication is broken.
Handling appropriate: My client-code is a network monitoring tool and such information should be logged down for server downtime analyzation. Thus exception should be directly handled.
Handling not appropriate: I got two application components which are communicating with RMI. The defect is a misconfiguration of the firewall. Application itself cannot react on this, it is a plain network setup defect.

Now Sun’s exception convention gets into problems: They told that Programming-Errors should always be mapped to unchecked exceptions… As shown above this does not work out, in some contexts the root cause of IOException is a Programming error (property-file loading) in some not (file-manager).

Way out of checked exceptions

Most likely Java standard won’t change this exception design-flaw, especially for backward compatibility reasons. But there is still a solution: When you are forced to handle checked exceptions constantly you can wrap them in custom unchecked exceptions (-> extending an own custom exception hierachy from RuntimeException). This way other client code does not need to bother to look at non-interesting exception. The implication of mentioned points could also be that your api-design should only offer unchecked exceptions in method declarations.

Following this clients are not distracted by always doing this try/catch duet and code further more gets much better readable. Of course you should not just shove all checked exceptions directly into a RuntimeException (one of the workaround I explained above), you should be more concrete and build up a deeper exception type-hierachy to make further handling easier. Besides you should chain checked exception and pass it to the unchecked exception’s constructor to later find out root causes better.

Of course at one point such unchecked exceptions need to be handled at the outmost layer latest to make a proper report possible (e.g notifying monitoring/logging, sending back a user-friendly error HTML-message). You really don’t want to spill the whole stack-trace to a HTML or SOAP response or make your application to completely always shutdown.

Conclusion

Java introduced checked exceptions, which seemed to be a good idea in the first place to enforce clients to “have to know” about certain error conditions. But in practice developers do not pass “uninteresting” exceptions in throws clause, because code gets crowded and diffult to understand. They merely tend to workaround with inappropraite exception handling. Further more the view on exceptions, wheter they are worth the be catched or not, is context based and cannot be anticipated. To avoid this problem api-designers or client code generally should go for unchecked exception and a custom unchecked exception type-hierachy.