in case anyone's wondering

vorbis

This was something that bugged me about java for a while. The lack of a decent way of being able to check if a string is numeric. Its probably of no interest to anyone else but in case it is I'll post it anyways.

All you have to do is convert a string into a char array. Then you loop through it and use Character.isDigit(char) to check if each char is numeric. I know it would have saved me a lot of hassle to have know it beforehand.

Hobbes

only works on ints though.

...
String s1 = new String("123");

if (isNumeric(s1)) 
    System.out.Println("Is a number: " + s1);
else
    System.out.Println("Is not a number: " + s1);
...

public boolean isNumeric(String text) {
   try {
        int i = Integer.parseInt(myString); 
        return true;
   }
    catch (NumberFormatException e) {
        return false;
   }
}

Enygma

There are also Float.parseFloat(str) and Double.parseDouble(str) etc methods.

I guess it's ok to use the thrown Exception for flow control here, normally it's fairly bad practice.
I guess you could call it an Exception to the rule!!

I'll get me coat...

Karoma

painful

as for the previous posts: handy... would people be willing to add entries like that more often, pref. in an additional forum (creating a 'repository' - similar to javaalmanac - i think it'd be very useful)

bonkey

Originally posted by Enygma
I guess it's ok to use the thrown Exception for flow control here, normally it's fairly bad practice.

Well, the underlying reason is generally considered bad practice (from what I've read) is because the try/catch mecahanism is actually fairly costly to implement, and so if it can be avoided it shoudl be for performance and overhead reasons.

So which is better...to try/catch a parse, or to look through every character??? Hard to say really. I generally cast like Hobbes did, because I can't think of any situation where I'd need to do this in a performance-requiring loop.

As a side-note on parsing strings to numerics char-by-char....you need additional logic for handling negatives (allow a minus, but only in position 1), decimals (allow a decimal point anywhere, but only one of them), and - god forbid - scientific notation (allow an e, but only after the decimal place, and now allow a second minus after the e before the digits which follow it, and complain if there arent any digits after the e).

Woof....

jc

Enygma

I'd also say it's bad practice from a maintainability point of view. Returning anything from a catch block can cause all sorts of confusion especially if there is a finally block.

Also Java programmers are used to using an if/else structure for flow control. Going outside of that structure is bound to cause some confusion.

Best practice in this case would be to go with Hobbes' solution and comment your code well.

Talliesin

Originally posted by bonkey
Well, the underlying reason is generally considered bad practice (from what I've read) is because the try/catch mecahanism is actually fairly costly to implement, and so if it can be avoided it shoudl be for performance and overhead reasons.

The cause and effect is muddled here. It's bad practice because try...catch (or for that matter any exception-handling mechanism in any language) has a role in exception handling and not elsewhere. Using it elsewhere will result in confusing code (GOTO on acid).
Because of this most of the time execution enters a try block it should not actually result in an exception; most of the time the try should be successful.
Because of this the generated code is optimised towards the case of the exception not being thrown, since that is the case that will occur most often (also it's frequently the case that the non-exceptional path is the one where efficiency is most needed).
This does of course increase the fact that it's bad practice to use exceptions as normal control flow, but it is not the original source.

That said, I would certainly be tempted to use exception handling here, especially since all of the "is this a number" logic is then handled by some very reliable code (generally one should trust standard functions and classes over one's own code).

Trojan

More on use of exceptions: joelonsoftware.

Talliesin

Originally posted by Trojan
More on use of exceptions: joelonsoftware.

Some useful stuff to be found on exceptions if you google for all the pages about how Joel was wrong in that article. I can see a bit of a point to his approach when it comes to Java, because you can't do RAII with Java, but in C++ his approach leads to code that is less efficient, less readable, and less reliable for no gain that I can determine. Even with Java I think exceptions are the way to go, they just aren't as good as C++ exceptions.
The article on Unicode from that page is also pretty flawed.

Trojan

Yeah, I agree, Joel is not always technically as accurate as he sounds - but he's always interesting.

The argument about exceptions - people are talking about these design issues without considering what it's like to debug the damn code. That's vital.

Talliesin

Originally posted by Trojan
The argument about exceptions - people are talking about these design issues without considering what it's like to debug the damn code. That's vital.

Yes, catch(...) is the worse culprit, since it will catch exceptions that shouldn't occur (i.e. if they are occurring there is a bug) and really 99% of the time catch(...) is the GOTO-on-acid that joel accuses all exceptions as being and I accuse exceptions that aren't for error handling as being.

That said, when exceptions are used as part of a thought-out error-handling strategy in a good design this increases the degree to which components can be separately tested and considered "trusted" enough to skip over calls to them in most debug runs. This makes debugging easier rather than harder.