CODEWITHSUNDEEP
javajakarta-eeexception
Barath
Barath

Reputation: 102

Which is better ? Many custom exception classes, or one exception class with many custom exception codes?

In a standard J2EE web application , assuming that class load times during app startup is not an issue, which would be a better approach in terms of maintainance, performace and usability ?

The first approach involves creating different exception classes, each to denote a particular error that occurs in the application. The class names are self explanatory, and that'll be used to provide error messages. (UPDATE : The number of classes is about 30 as of now, and it'll continue to increase in the near future, probably upto 70 or 80 atmost)

The secodn approach involves creating one exception class, and a bunch of exception codes where each code represent a particular error in the app. The error codes are obtained from the exception, and is used to provide error messages.

Upvotes: 6

Views: 2708

Answers (4)

Ankur Singhal
Ankur Singhal

Reputation: 26077

It is more or less dependent on your business needs. From my point of view, having multiple custom exception classes is the right approach to go.

Learn from Java, how many it manages.

In any given application there can be n types of validation requirements, some can be represented under one group and some into another, but fitting everything into single does not serve the intended purpose in terms of logic and business.

Let's say we have a class called UserAuthenticationException.

This exception can represent multiple different error conditions and give different messages for each case; for example:

1.) Invalid username/passwords

2.) Session timeout

3.) Multiple active token of same user in different machines etc...

Handling errors with instanceof and handlers for each exception class is much easier than handling errors based on error messages.

Upvotes: 1

ddyer
ddyer

Reputation: 1786

Most exceptions within an application are handled by some generic recovery; probably involving generating a log file and killing or restarting the process. There's no reason for these to be different types.

In the less usual case where a specific recovery procedure is expected, there should be a specific error class for that procedure.

Upvotes: 0

Adam Siemion
Adam Siemion

Reputation: 16039

From the code maintabaility point of view, the first approach, as it results in cleaner/simpler code. The name of the exception class gives you the cause of the problem without having to inspect the attributes of the exception class.

From the performance point of view, the second approach, "fewer exception classes mean a smaller memory footprint and less time spent loading classes" (Effective Java, item 60). Keep in mind however, that "premature optimization is the root of all evil" so until you confirm your application has performance issues do not try to optimize it.

Upvotes: 1

Mr Zorn
Mr Zorn

Reputation: 1913

The choice is ultimately up to you, as both can be valid. I personally find it is better to make many custom exceptions, particularly if they are going to be used multiple times for the simple fact that if I want to change the error code or message a certain type of exception "File did not successfully upload" or "Item not found" or whatever the case may be, I only have to do it in one place, the custom exception, and not in every place which uses it.

This also allows you do catch those specific exceptions as the are thrown in other parts of your code. Perhaps you need to do extra work if the exception was a "File not found" exception, in which case you can catch only those exceptions that you want to handle in different ways - this would be much more difficult if they were all the same class.

Classes exists in OOP for a reason and you should take advantages of those reasons.

Upvotes: 0

Related Questions