Newby - avoiding catch for code flow vs reuse of validation logic in framework

[Steve Jorgensen]

Hi all,

In the code I'm working on to learn Java, I wanted to check to see if a string
can be converted to a BigDecimal, and get the BigDecimal value if so. There is
no assumption that the string is probably a valid BigDecimal, just that it might
be, and I want to get the converted value if so.

In my code, I used a Try with an empty Catch so that the string conversion would
either succeed or fail which would both test and do the conversion in 1 step.
This seems to break 2 commonly quoted best practices, though. One is to never
use an empty Catch, and the other is to never use exception handling for
something other than exception handling. The alternatives, though, seem to
involve me writing my own code to check the validity of the string as a
BigDecimal which would be duplicating logic that is already in the standard
classes (the code that validates and raises the exception) and increases the
likelihood of bugs.

Opinions?

Thanks,

- Steve Jorgensen

[Gerard Oberle]

In my opinion, you are taking the correct approach. While rules
aren't always made to be broken, the two you cite certainly strike me
as candidates.

The admonition against using exceptions for non-exceptional behavior
is to avoid using the throw/catch mechanism for flow control. For the
most part, the "structured programming" principles that came into
vogue in the late 70s provide most, if not all, of the flow control
constructs one would need. So the idea is, don't use throw/catch
where if (condition) {...} will do.

As for never having empty catch blocks, I am unsure where this comes
from. Within the context of the BigDecimal class, encountering
non-decimal characters is exceptional. But within your code, you
simply don't care. So your code should express that.

Cheers!
- Jerry Oberle

[Steve Jorgensen]

On 25 Jul 2003 19:53:54 -0700, go*****@hotmail.com (Gerard Oberle) wrote:

In my opinion, you are taking the correct approach. While rules
aren't always made to be broken, the two you cite certainly strike me
as candidates.

The admonition against using exceptions for non-exceptional behavior
is to avoid using the throw/catch mechanism for flow control. For the
most part, the "structured programming" principles that came into
vogue in the late 70s provide most, if not all, of the flow control
constructs one would need. So the idea is, don't use throw/catch
where if (condition) {...} will do.

As for never having empty catch blocks, I am unsure where this comes
from. Within the context of the BigDecimal class, encountering
non-decimal characters is exceptional. But within your code, you
simply don't care. So your code should express that.

Cheers!
- Jerry Oberle

Thanks very much for your insight.