is there any reason you don't want to catch it? If it's performance, as far as I'm aware it's not much difference going through a try-catch block UNLESS the exception is actually thrown, then there is plenty of overhead. But if the error is catastrophic
–
dann.devDec 2 '11 at 0:01

No, because the error is not suppose to happen (i.e. programming error, or runtimeexceptions).
–
PwnnaDec 2 '11 at 0:03

Whoops, posted the above before finishing. Well errors are never 'suppose' to happen! But it sounds like you are throwing the error for the sake of it. I thinkyou need to rethink whether you want to be throwing the error in the first place
–
dann.devDec 2 '11 at 0:29

For debugging purposes. Example is that wrong argument format, or something like that (such as a negative height or a negative weight)
–
PwnnaDec 2 '11 at 20:49

Thanks! This is helpful for writing non-optimistic code, where I can have an exception that SHOULD never happen but is there to let another developer know that they forgot something in their code.
–
Adam LockhartJul 22 '13 at 19:55

NOTE: This is often considered bad style, however, and people may tell you so. The often-cited reason is that, even if you're not going to do anything with the exception, that in most cases you should at least log it somewhere, notify the user, or take some other appropriate action depending on what you app is doing, and what caused the exception in the first place. If you're not sure why an exception is being thrown (maybe it's a bug you haven't solved yet), then generally you should at least log it so you can figure it out later.

Turns out what I needed was RuntimeException, as the error is never suppose to happen (the exception should never been thrown unless there's a bug in the code), which I completely forgot about
–
PwnnaDec 2 '11 at 0:04