CODEWITHSUNDEEP
exceptionlanguage-agnostic
Tara
Tara

Reputation: 397

When to throw exceptions

I did a search for this and came across this question. The top answer was most helpful, but I wanted some clarification and do not have enough reputation to post a comment, so I am creating a new question for it.

Basically, the user, "The Digital Gabeg" states that when a presupposition of the code is not met, throw an error. The example given is if a method returns true if the length of a List<> is over 50, and false if not. If the object passed to the method is not a List<> however, the method could not accurately return true or false, so instead of returning anything, it throws an error (although strictly speaking, that logic isn't quite accurate, if an object isn't of an object type that has members (i.e., a List<> or array) then it's still false that it's length is over 50 [because in order to have a length over 50, it would need to first have a "length" defined for the object]).

The most obvious hole in this example is that be specifying the method's parameter to be a List<> would avoid even being able to pass anything else to the method. That's not really my question though. For the sake of argument, let's just assume for whatever reason you can't ensure an object passed to the method is a List<> at compile time - even if that were the case, this sort of thing can be gotten around by changing the return type of the method from a boolean to an int and specifying a return value of 0 for false, 1 for true, and -1 for anything else. This might be an arbitrary assignment of values, but it handles the situation without the need for throwing an exception. You could even have it return other values besides -1, 0, and 1 to represent other things. For example, if an array was passed rather than a List<>, you could use the values 2 and 3 for true and false with the caveat that while the object provided did (or did not) have more than 50 members, the object passed wasn't strictly a List<>....as long as this sort of thing is provided in the documentation and/or comments.

So I guess my question then is, since premise of the answer given was that exceptions should be thrown when the assumptions behind what they are trying to do are undermined, and there is technically a workaround for the example provided, are such workarounds preferable to throwing exceptions if they can be found, or is it preferable to throw the exception, and if it depends on the situation, what are the determining factors?

Upvotes: 0

Views: 51

Answers (1)

Lasse Heemann
Lasse Heemann

Reputation: 36

In the case you describe throwing an error is definitely the better option. When using a function, lets say

boolean x = listBigEnough(list)

we can assume how the function works. If we instead have

int x = listBigEnough(list)

We have no clue what x represents. Is it how many elements we need to add to the list so that it is big enough? What does x=-3 mean? Maybe we assume 1=true 0=false and do

if x==0 {
//increase size of list
} else {
//continue as usual
}

But what happens if there is an error and listBigEnough returns -1?

If the program crashes because the writer of listBigEnough made it throw an error we know how to fix our code. Also errors don't allways crash the program, we can catch the errors

list = //user input
try {
  if listBigEnough(list) {
    //do thing
  } else {
   //tell user to get larger list
  }
} catch (NotAListError) {
// tell user to give a list
}

Upvotes: 1

Related Questions