Tag Info

New answers tagged

1

Does it matter which type of exception to throw as long as the error message is useful? In cases like this, I often defer to the official docs for definitions and usage examples. The docs for RangeError are a bit terse: RangeError Raised when a given numerical value is out of range. [1, 2, 3].drop(1 << 100) raises the exception: ...


0

I think what you are looking for is the finally clause. This will allow you to run some other code, even in the event of an exception. boolean importantFlag = false; //Default value try { importantFlag = getFlag(); } catch (Exception e) { //rethrow exception } finally { //This will run whether or not there is an exception. ...


0

I'm not sure I understand the question, but here's my take on it. In these cases you might want to create a wrapper function that calls the unsafe function safely, and always returns a value. Falling back on a default value if there is an exception. function boolean getFlagSafely(boolean defValue) { try { return getFlag(); } catch(Exception) ...


-2

If you're actually in Java, finalize the variable. boolean foo() { final boolean importantFlag; try { importantFlag = getFlag(); } catch (Exception e) { throw new RuntimeException(e); } return importantFlag; } This will compile and run safely. If you, however, removed the throw statement from the catch block, ...


-1

When dealing with exceptions, it usually pays to have as much code as possible inside the try block. Not just the function itself that could throw, but also everything that uses the return value from the function. In your case, I would write it as: try { boolean importantFlag; importantFlag = getFlag(); doSomeStuff(importantFlag); // more ...


9

Aside memory allocation reason (which, by the way, looks like premature optimization to me), there are other elements in favor of catching invalid arguments as soon as possible: Stack trace When an exception occurs, you expect the few last lines to show you the location of a mistake. Having to search from bottom to top of the stack to find the culprit will ...


2

The answer is: it depends. In your example, you should let List throw its exception and let any exception bubble up the chain. Your example method should not know or care whether the value is invalid, since it's sole purpose is to pass it along to something else. If you were using the value in ReadAll as something other than an argument to List, you ...


1

Gotta disagree with the accepted answer. The argument about allocating memory, etc. is only relevant if this method is called often with an illegal argument. The purpose of checking arguments (programming by contract) and throwing exceptions is primarily to fix bugs during development. During development, efficiency is not an issue. Combined with unit ...


0

Short answer: no, it's not OK. Because even calling the constructor of List means, from the compiller's perspective: memory allocation for the new object, writing references for it in the reference table, accessing other subroutines just to create the new List object, just to have it basically blow up in your face by throwing an exception. I know it doesn't ...


3

Neither. As others have pointed out, it is clearly not an IllegalStateException. And better than IllegalArgument would be FileNotFoundException or ParseException, (or maybe XMLParseException) which exactly match your description of "bad things" 1 and 2.


7

The Javadocs of IllegalStateException say Signals that a method has been invoked at an illegal or inappropriate time I would argue, that it does not matter when your method is called or in what state the JVM or your context is - the parsing error will remain as long as the file is not correct. So it seems to me, that an IllegalArgumentException is ...


1

It is surely decreasing the code readability. I would say, if you have chance, then avoid nesting try-catches. If you have to nest try-catches, always stop for a minute and think: do I have the chance to combine them? try { ... code } catch (FirstKindOfException e) { ... do something } catch (SecondKindOfException e) { ... do something else } ...


1

IMHO if that is ok depends mostly on the context of the Do method, and what you know about the stuff in the try-block. Lets assume you have an UI application, and the Do part is just a Button-Click handler. Lets further assume the part within the try block does some fairly complex non-UI things which might fail with any kind of unforseeable exception (but ...


2

Instead of catching the exception, why don't you just let it bubble up to the calling code? So either your model or controller (depending on how you call InsertAccount) would have the ability to catch the exception (or, in fact, any exception) and display it to the user in an appropriate fashion. My general rule is to only catch an exception when I can do ...



Top 50 recent answers are included