3

This is more of an OO design question.

So, I've got an UnsuportedLocaleException which will be used only on the initialization stage of an app. I've got two options:

  1. Extend RuntimeException and leave it out there without any handling logics (acts as a config => apply defaults if wrong).
  2. Extend an Exception and handle it (involves all the redundant coding etc.).

I like the first one more, but not sure if that'll be correct design.

Denys S.
  • 6,358
  • 12
  • 43
  • 65
  • duplicated http://stackoverflow.com/questions/4233793/proper-use-of-runtimeexception – Damian Leszczyński - Vash Feb 11 '11 at 17:12
  • 1
    You should eside first whether you want to force the caller to handle the exception or not. If the caller cannot do anything useful and should die, extend the RuntimeException or possibly Error. – Peter Lawrey Feb 11 '11 at 17:18
  • @Vash, It's a question of "what's a better OO design in my particular case", not a "when should I use them" question. Please read the essence not the title. – Denys S. Feb 11 '11 at 17:20
  • possible duplicate of [In Java, when should I create a checked exception, and when should it be a runtime exception?](http://stackoverflow.com/questions/499437/in-java-when-should-i-create-a-checked-exception-and-when-should-it-be-a-runtim) – orangepips Feb 11 '11 at 19:20
  • But given your question, it can be hardly said more than Vash said. It all depends on how you're going to live with the exception. You may and sometimes must catch RuntimeException, too. There are two important differences: 1. you must declare or check a checked exception, which makes it sure that you don't forget it, 2. you can't pass you own checked exception throw foreign methods (unless subclasses of a declared one). That's all. – maaartinus Feb 12 '11 at 06:16

3 Answers3

9

Seems entirely reasonable to me. RuntimeException is a good base class for exceptions which calling code shouldn't try to "handle" - i.e. when they indicate the kind of failure which probably means that either the whole app or (possibly, for servers) the request should simply be abandoned.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • This sounds more like an `Error`. RuntimeException, on the other hand, is perfectly fine to handle, but sometimes it is just unreasonable. NumberFormatException is a good example - if your string just matched "\\d{1,3}", then you just know there won't be any NumberFormatException, so there's no need to handle it. It's more like an assert in such case, which will prove very useful if there's a bug in the regexp matching code. But if you just got a string from only god knows where, then it is perfectly fine to catch it and handle properly. – Sergei Tachenov Feb 11 '11 at 17:29
  • @Sergey: I view NumberFormatException as an unfortunate example of `RuntimeException`. I regard `Error` as something even more serious, usually do to with the operating environment itself going wrong (VM death etc). It doesn't sound like this should be an `Error` to me. It's definitely a grey area though. – Jon Skeet Feb 11 '11 at 17:32
  • @Jon, I agree, this case doesn't sound like it should be an `Error`. And after looking at the list of RuntimeException descendants, I began feeling that you're right about NumberFormatException, it definitely doesn't feel like it belongs there. Most of them just reflect programming errors. – Sergei Tachenov Feb 11 '11 at 17:51
  • How is `Integer.parse(s)` with `s`=`""` different from `1/x` with `x`=`0`? Both may be programming errors and both `s` and `x` may come from the user. – maaartinus Feb 12 '11 at 06:21
  • @maaartinus: One difference is that it's incredibly easy to test for x being 0 before performing the calculation. It's harder to predict whether parsing the value will work without trying it. – Jon Skeet Feb 12 '11 at 07:27
  • @maartinus, Jon is right. By pure coincidence, I tried making a regular expression that matches any valid string representation for an int. I succeeded, but it looked terrifying. – Sergei Tachenov Feb 12 '11 at 08:04
  • I agree, it's not easy, especially, when the exact range is considered. However, there's no reason not to catch the NFE, is it? OTOH, when it occurs often, you are better off with your regex, since it's probably faster. Maybe there should be `Integer.canParse(String)` in addition to `Integer.parse(String)`, then the test would be easy. Can you paste the regex here? Or it could be a good question, should I ask it? – maaartinus Feb 12 '11 at 19:00
2

The first one is fine. There are many exceptions that subclass RuntimeException.

vz0
  • 32,345
  • 7
  • 44
  • 77
2

There is several opinions here.

First (classic) says that in most cases you should use checked exceptions. In this case methods must either declare this exception as a part of its signature or catch it. This method has advantages that the interface is always clear and each layer care about its exceptions. But the method is pretty verbose. Sometimes your code becomes much longer, you have to right several try/catch statements instead of call a coupe of methods and write one if.

Other approach is to use runtime exceptions only. This philosophy says that you do not have to handle exceptions because you have nothing to do with them. In this case all exceptions are runtime and are caught and processed in one central module. For example Spring framework uses this approach.

So the answer is what are you developing. If this is stand alone library use checked well defined exceptions. If it is application or application framework you can use the runtime exceptions like Spring.

AlexR
  • 114,158
  • 16
  • 130
  • 208