Carried throws declarations for RuntimeExceptions

Question

Suppose I have a method or a constructor that uses another method or constructor internally that declares a RuntimeException can be thrown.

// Example:
public MyClass(Object arg) {
    setVar(arg);
    // Not responsible for dealing with the exception
}

public void setVar(Object arg) throws MyRuntimeException {
    if(!isValidArg(arg))
        throw new MyRuntimeException("Got you, evil argument!");
    // Do something
}

In this case the RuntimeException is thrown if for example necessary preconditions are not fulfilled.

Q: Should the wrapping method/constructor declare the same Exception, if it's argument could cause the Exception to be thrown?

@LutzHorn what do you mean by that ? why shouldn't he do it ? Unless the method does heavy processing it shouldn't be a problem — giorashc, Mar 08 '13 at 12:41
Well, the constructor should construct the instance. It strikes me as odd to call a method of this instance before it is completely constructed. — , Mar 08 '13 at 12:44
You should not subclass RuntimeExceptions, unless you are really really sure what you are doing. They are very sneaky and can creep up on you. Use checked exceptions (subclasses of Exceptions) instead. As you are declaring the exception, this does not make any difference for your question though. — pushy, Mar 08 '13 at 12:46
@LutzHorn don't worry it will work with no harm. Of course a clean constructor will not include such calls as they might be unsafe if they use members which have not been initialized yet — giorashc, Mar 08 '13 at 12:50
@Perception care to elaborate on that? I am aware that some people do not like the concept of checked exceptions that force you to declare exceptions that you do not really care about, but at least that way, you know that something can go wrong and can handle them. With Runtime Exceptions you have to depend on documentation and testing. In my opinion, you should therefore only use RuntimeExceptions if you are sure that the client can do nothing to recover from the exception... — pushy, Mar 08 '13 at 12:52
@LutzHorn Although it's not always safe it can help you encapsulate the logic of for example setting a variable in the setter. — Samuel, Mar 08 '13 at 12:54
@pushy - the decision on using checked vs unchecked exceptions is normally based on wether observable input of the caller can be attributed to causing the exception, as opposed to some inner working of the called function itself. Subclassing a RuntimeException vs using it in the current context are two *entirely* different things. — Perception, Mar 08 '13 at 12:59
@Perception Agreed, I may have gone overboard a bit with my advice. Still, in my opinion it is better to use checked exceptions, unless you really know what the differences are, and made a informed decision to use them. I know to many examples where RuntimeExceptions are used with ignorance, and lead to some heavy headaches later on. — pushy, Mar 08 '13 at 13:09
@pushy I understand your point of view, but I think an overuse of checked exceptions can also lead to a lot of unnecessary code (especially dealing with exceptions that you know cannot be caused logically). Also i've seen a lot of cases where people begin to catch those exceptions just to do nothing (or nothing useful) with it and that can make your code *way* harder to debug. — Samuel, Mar 08 '13 at 13:18
@Samuel You are right, of course. Both ways have their own set of problems. But I still favor using checked exceptions over unchecked exceptions, especially with developers who are not firm what the differences are. You obviously are and have very good reasons to do it this way, so my advice was uncalled for at this point. Sorry for that ;-) — pushy, Mar 08 '13 at 13:47

score 3 · Accepted Answer · answered Mar 08 '13 at 12:41

3

It really depends on the context that the code is in. If you want to make something that is self contained, like a Library, you might want to catch the Exception inside the class, just to make the use of your code cleaner.

However if you're making code as part of a project, then I would, as you say, "carry the throws exception" until it doesn't make sense, semantically.

answered Mar 08 '13 at 12:41

christopher

26,815
5
55
89

2

I think "carry the throws until doesn't make sense, semantically" makes sense. I wanted to note that catching an exception is not always possible though so often you only have the choice between throw a checked exception, throw runtime exception and declare it or do not declare it. – Samuel Mar 08 '13 at 13:08

score 1 · Answer 2 · answered Mar 08 '13 at 12:44

1

I would declare it if it is not supposed to be handled inside the wrapping method - the same as with checked exceptions.

Anyway good to have such a hint for method even for unchecked exceptions. The client will decide if it needs to be handled.

answered Mar 08 '13 at 12:44

Vasyl Keretsman

2,688
2
18
15

giorashc · Answer 3 · 2013-03-08T12:45:29.877

0

RuntimeExceptions are thrown without the need to include it in the throws signature for neither of the methods.

You should read this about runtime exception

edited Mar 08 '13 at 12:45

answered Mar 08 '13 at 12:39

giorashc

13,691
3
35
71

That is correct, they do not need to be thrown, but sometimes you want to indicate an exception can be thrown and let the user of the class decide wether or not he will handle it. If for example the argument he is passing along is based on user input and might be erroneous he might catch it, but if he's sure it's correct he doesn't. – Samuel Mar 08 '13 at 12:46
If that is the case then why use runtime exceptions ? He can easily use checked exceptions – giorashc Mar 09 '13 at 12:13
I think some people will prefer to throw checked and some will prefer to throw unchecked exceptions. In my case that's not a point of choice though, the runtime exception is being thrown and I am trying to find the best way to handle it in a wrapping method not responsible for the handling. – Samuel Mar 09 '13 at 16:08

score 0 · Answer 4 · answered Mar 08 '13 at 12:47

0

no, Runtime Exceptions are not checked i.e. compiler does not forces you to deal with them. But as a good programming practice you can handle the exception like

public MyClass(Object arg) {
  try{
    setVar(arg);
}
catch(MyRuntimeException exp){
   // code if exception arises
}

answered Mar 08 '13 at 12:47

navyad

3,752
7
47
88

That is true, but the constructor might not be responsible for dealing with the exception. – Samuel Mar 08 '13 at 12:48
Its a bad idea *generally* to catch exceptions like this in a constructor unless you are *very* sure you can complete the construction of the object in a way that makes sense. If not, its better to let the exception propagate up to the caller. – Perception Mar 08 '13 at 12:52
if you are calling a method from constructor , and that method may throw an exception then you may not be sure anyway that you object will be constructed – navyad Mar 08 '13 at 12:54
@naveenyadav Actually you are sure that if you throw an exception the constructor will not finish and the object will *not* be constructed – Samuel Mar 08 '13 at 12:56
@naveenyadav Yup, but say you make a class PositiveInteger and it is constructed with an int. If the int is negative you cannot really handle that exception because you cannot create a PositiveInteger with a negative integer. That should violate your class constraint. So in that cause you do not finish creation and pass on the exception to the creator to indicate the error. – Samuel Mar 08 '13 at 13:00
yes thats the point. in your example you are calling a method from a constructor(caller of method) . if something wrong(exception) happens in method , either you can handle that or you can throw that exception. You are throwing exception from method and saying to constructor that "hey buddy, sorry cannot finish that code , something bad happens, i'm sending this exception (exception) , see if you can handle it or not". Then its upto constructor if you handle in there object will be constructed and you can get to know that something "wrong" has happened and can deal with it – navyad Mar 08 '13 at 13:10
@naveenyadav That is true, and i added a comment in my code to clarify. My question is assuming the wrapper method, the constructor in this case, does not want to deal with that specific exception. – Samuel Mar 08 '13 at 13:26
if constructor does not want to deal with it. then wrapping method or constructor does not needs to declare a Runtime exception. But in that case object construction will not be completed – navyad Mar 08 '13 at 13:51

Carried throws declarations for RuntimeExceptions

4 Answers4