Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Computing
Conference & Expo
November 2-4, 2009 NYC
Register Today and SAVE !..

2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
In many cases, the end of the year gives you time to step back and take stock of the last 12 months. This is when many of us take a hard look at what worked and what did not, complete performance reviews, and formulate plans for the coming year. For me, it is all of those things plus a time when I u...
SYS-CON.TV
Mistakes to Avoid When Handling Java Exceptions | @CloudExpo #Java #Cloud #Analytics
You either need to specify or handle a checked exception

Seven Common Mistakes You Should Avoid When Handling Java Exceptions
By Thorben Janssen

Handling an exception is one of the most common but not necessarily one of the easiest tasks. It is still one of the frequently discussed topics in experienced teams, and there are several best practices and common mistakes you should be aware of.

Here are a few things you should avoid when handling exceptions in your application.

Mistake 1: Specify a java.lang.Exception or java.lang.Throwable
As I explained in one of my previous posts, you either need to specify or handle a checked exception. But checked exceptions are not the only ones you can specify. You can use any subclass of java.lang.Throwable in a throws clause. So, instead of specifying the two different exceptions that are thrown by the following code snippet, you could just use the java.lang.Exception in the throws clause.

But that doesn't mean that you should do that. Specifying an Exception or Throwable makes it almost impossible to handle them properly when calling your method.

The only information the caller of your method gets is that something might go wrong. But you don't share any information about the kind of exceptional events that might occur. You're hiding this information behind an unspecific throws clause.

It gets even worse when your application changes over time. The unspecific throws clause hides all changes to the exceptions that a caller has to expect and handle. That might cause several unexpected errors that you need to find by a test case instead of a compiler error.

Use specific classes
It's, therefore, much better to specify the most specific exception classes even if you have to use multiple of them. That tells the caller of your method which exceptional events need to be handled. It also allows you to update the throws clause when your method throws an additional exception. So your clients are aware of the change and even get an error if you change your throws clause. That is much easier to find and handle than an exception that only shows up when you run a particular test case.

Mistake 2: Catch unspecific exceptions
The severity of this mistake depends on the kind of software component you're implementing and where you catch the exception. It might be ok to catch a java.lang.Exception in the main method of your Java SE application. But you should prefer to catch specific exceptions, if you're implementing a library or if you're working on deeper layers of your application.

That provides several benefits. It allows you to handle each exception class differently and it prevents you from catching exceptions you didn't expect.

But keep in mind that the first catch block that handles the exception class or one of its superclasses will catch it. So, make sure to catch the most specific class first. Otherwise, your IDEs will show an error or warning message telling you about an unreachable code block.

Mistake 3: Log and throw an Exception
That is one of the most popular mistakes when handling Java exceptions. It might seem logical to log the exception where it was thrown and then rethrow it to the caller who can implement a use case specific handling. But you should not do it for the following three reasons:

  1. You don't have enough information about the use case the caller of your method wants to implement. The exception might be part of the expected behavior and handled by the client. In this case, there might be no need to log it. That would only add a false error message to your log file which needs to be filtered by your operations team.
  2. The log message doesn't provide any information that isn't already part of the exception itself. Its message and stack trace should provide all relevant information about the exceptional event. The message describes it, and the stack trace contains detailed information about the class, method, and line in which it occurred.
  3. You might log the same exception multiple times when you log it in every catch block that catches it. That messes up the statistics in your monitoring tool and makes the log file harder to read for your operations and development team.

Log it when you handle it
So, better only log the exception when you handle it. Like in the following code snippet. The doSomething method throws the exception. The doMore method just specifies it because the developer doesn't have enough information to handle it. And it then gets handled in the doEvenMore method which also writes a log message.

Mistake 4: Use exceptions to control the flow
Using exceptions to control the flow of your application is considered an anti-pattern for two main reasons:

  1. They basically work like a Go To statement because they cancel the execution of a code block and jump to the first catch block that handles the exception. That makes the code very hard to read.
  2. They are not as efficient as Java's common control structures. As their name indicates, you should only use them for exceptional events, and the JVM doesn't optimize them in the same way as the other code.

So, better use proper conditions to break your loops or if-else-statements to decide which code blocks should be executed.

Mistake 5: Remove original cause of the exception
You sometimes might want to wrap an exception in a different one. Maybe your team decided to use a custom business exception with error codes and a unified handling. There's nothing wrong with this approach as long as you don't remove the cause.

When you instantiate a new exception, you should always set the caught exception as its cause. Otherwise, you lose the message and stack trace that describe the exceptional event that caused your exception. The Exception class and all its subclasses provide several constructor methods which accept the original exception as a parameter and set it as the cause.

Mistake 6: Generalize exceptions
When you generalize an exception, you catch a specific one, like a NumberFormatException, and throw an unspecific java.lang.Exception instead. That is similar to but even worse than the first mistake I described in this post. It not only hides the information about the specific error case on your API, but it also makes it difficult to access.

As you can see in the following code snippet, even if you know which exceptions the method might throw, you can't simply catch them. You need to catch the generic Exception class and then check the type of its cause. This code is not only cumbersome to implement, but it's also hard to read. It get's even worse if you combine this approach with mistake 5. That removes all information about the exceptional event.

So, what's the better approach?

Be specific and keep the cause
That's easy to answer. The exceptions that you throw should always be as specific as possible. And if you wrap an exception, you should also set the original one as the cause so that you don't lose the stack trace and other information that describe the exceptional event.

Mistake 7: Add unnecessary exception transformations
As I explained earlier, it can be useful to wrap exceptions into custom ones as long as you set the original exception as its cause. But some architects overdo it and introduce a custom exception class for each architectural layer. So, they catch an exception in the persistence layer and wrap it into a MyPersistenceException. The business layer catches and wraps it in a MyBusinessException, and this continues until it reaches the API layer or gets handled.

It's easy to see that these additional exception classes don't provide any benefits. They just introduce additional layers that wrap the exception. And while it might be fun to wrap a present in a lot of colorful paper, it's not a good approach in software development.

Make sure to add information
Just think about the code that needs to handle the exception or yourself when you need to find the problem that caused the exception. You first need to dig through several layers of exceptions to find the original cause. And until today, I've never seen an application that used this approach and added useful information with each exception layer. They either generalize the error message and code, or they provide redundant information.

So, be careful with the number of custom exception classes you introduce. You should always ask yourself if the new exception class provides any additional information or other benefits. In most cases, you don't need more than one layer of custom exceptions to achieve that.

More about Java Exceptions
As you've seen, there are several common mistakes you should try to avoid when you handle Java exceptions. That helps you to avoid common bugs and to implement applications that are easy to maintain and to monitor in production.

If this quick list of common mistakes was useful, you should also take a look at my best practices post. It provides you with a list of recommendations that are used by most software development teams to implement their exception handling and to avoid problems like the ones described in this post.

When using Retrace APM with code profiling, you can collect exceptions directly from Java, without any code changes!

The post 7 Common Mistakes You Should Avoid When Handling Java Exceptions appeared first on Stackify.

About Stackify Blog
Stackify offers the only developers-friendly solution that fully integrates error and log management with application performance monitoring and management. Allowing you to easily isolate issues, identify what needs to be fixed quicker and focus your efforts – Support less, Code more. Stackify provides software developers, operations and support managers with an innovative cloud based solution that gives them DevOps insight and allows them to monitor, detect and resolve application issues before they affect the business to ensure a better end user experience. Start your free trial now stackify.com

SOA World Latest Stories
When building large, cloud-based applications that operate at a high scale, it’s important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. “Fly two mistakes ...
Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations, in addition to network and sy...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand usin...
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portabil...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is founda...
Using new techniques of information modeling, indexing, and processing, new cloud-based systems can support cloud-based workloads previously not possible for high-throughput insurance, banking, and case-based applications. In his session at 18th Cloud Expo, John Newton, CTO, Founder an...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021


SYS-CON Featured Whitepapers
Most Read This Week
ADS BY GOOGLE