1

I'm developing an RPC Web Service that offers methods to clients and I want to use Exceptions to handle errors within the server application, as to automatically generate a response with an error header and, more important, a custom error code (integer). I have created a base CustomException class which holds an integer and the message.

Should I create a new class for every exception on every method, with its custom error code hard-coded on the class? Or is there another approach to this problem?

e.g. let's suppose I have a Login method which can have two exceptions, "UnknownUsername" and "InvalidPassword" (just as an example; as Tieston T. commented, it's not a good practice to return information on authentication). The approaches I can think of so far are:

  • Using a LoginException class and setting the error code on the internal method
  • Creating a UnknownUsernameException and an InvalidPasswordException class, inheriting LoginException, and hard-code the error code on each class
  • 1
    It's worth noting that standard security protocol says that you don't tell the calling application what was invalid during an authentication attempt. – Tieson T. May 20 '14 at 05:24
  • I just wrote down the first example I thought of; I don't actually use authentication on my service but anyway that's a really useful sidenote. – NaraJeamfry May 20 '14 at 05:26
  • 1
    imho `LoginException` is not an exception. It's expected that a login might fail. – jgauffin May 20 '14 at 05:35
  • Simplest implementation is probably @Harik's second suggestion; have a custom error type that has at minimum an error code, with an optional message. You can provide users of your API with a guide of some sort that explains what the various error codes mean. – Tieson T. May 20 '14 at 05:41

3 Answers3

1

You can create separate exception classes if you want.

Or you can create ONE single custom exception class, which will contain an ENUM holding error_code and messages for various types of exception that could occur.

Your custom exception class will have contructor which will accept the ENUM and a message.

Whenever, code throws custom exception, it will populate the enum through constructor. You can lookup the error code and error message from it and pass it across to client accordingly.

This will help you log the exception (for internal uses) and respond to client through one single class.

Hirak
  • 3,601
  • 1
  • 22
  • 33
  • I was watching [this question](http://stackoverflow.com/questions/6310241/pros-and-cons-of-implementing-a-generic-custom-exception), but then realized that the only reason user alexn disapproved it is because of catching and flow control; and in my case it isn't really needed. So I think this is probably the best answer to the question. – NaraJeamfry May 20 '14 at 05:55
0

I think you should first search the standard java exception to see if Java Exceptions have one already that satisfy your need, if not you can find the nearest one and override it to satisfy your need.

for me i prefer to combine the following exception with one exception UnknownUsername and InvalidPassword exception, please don't tell any one that the exception thrown regarding username or password also YOU. so don't inherit from LoginException

mohamed sulibi
  • 526
  • 3
  • 12
0

Generally it is better to use standard Exception classes. This is a good source on exception handling best practices that I find useful.

I think custom exception classes should have created based on how the application is going to treat them. For example if you going to catch Login-related exceptions and show a "login-failed" message to user probably you should create one class. For internal use and logging you can add more details to objects.

Also it is better for maintainance purposes to not define hard-code error-codes, in case some new error-codes add later.

Community
  • 1
  • 1
Milad
  • 89
  • 1
  • 8
  • Very useful link! I didn't find any standard Exception that was related with the actual problem (Service exception that should be returned to the client), so Hirak's answer makes sense (creating a custom Exception class). – NaraJeamfry May 20 '14 at 06:00