# Basic question: How to determine if a string is a number?

• Hello,

As it stands now, everytime I want to check if a string is a valid number.. I have to do a Integer.parse(stringVar) and wrap it around a try/catch block.

I have a feeling that there has to be a "better and cleaner" way to do this. Any ideas?

PS: Sorry for asking such a basic question amongst all you pros
I have limited programming experiance (I am CS student). However, I have learnt that if you get the "there has to be a better way to do this" feeling, then there most likely is a better way to do it. Everytime I have followed up on that feeling, I've learnt something new and cool

Thanks.

• So basicly you are trying to parse the number out of string?

nonDev

• Suppose there was such a thing:

public static boolean isInt(String s) {
try {
Integer.parseInt(s);
return true;
}catch( Exception e) {
return false;
}
}

Would it do you any good? You would STILL have to write:

int i;
if(isInt(s)) {
i = Integer.parseInt(s); // REQUIRES A TRY block.
}

The altenative would be to write a function that returns the integer right away, and write
i = getInt(s);

But now what do you do when it's not a valid number? you could return 0, or -1, but those may be actually the value of the string. So the only non-result you can return is to throw an exception..

See the pattern?

Of course, you can write a function that will try to parse a string as an Integer, Float, Double, Hex, Binary, anything.. That way you can limit most of the try blocks to the inside of that function..

Depending on the application, you can come up with a function that sets a default value, something like what would be used when reading a config file.

int getSetting(String value, int default) {
try { return Integer.parseInt(value); }
catch(Exception e){ return default; }
}

now you can write code without littering every other statement with a try/catch block.

• hmm, I see. So in other words, there is no direct way to circumvent "throwing the exception".

Thanks

• @nonDev said:

So basicly you are trying to parse the number out of string?

nonDev

I don't think he got your hint for int32.TryParse() ...

•     @Nandurius said:

Would it do you any good? You would STILL have to write:

int i;
if(isInt(s)) {
i = Integer.parseInt(s); // REQUIRES A TRY block.
}

See, thats the thing. I am not trying to get the Integer itself, I am
just trying to determine if the string is a valid number. Why? Suppose
I am building a database frontend in .NET. Look at this

row["Price"]=priceTextBox.Text

Now suppose the user enters an invalid value in the priceTextBox control, this will result in the database throwing an error. Therefore, you have to surrounding the above statement in a try/catch block or else the program will crash.
Now you may say, "well, let the database worry about maintaining data integrity". But you see, we've been taught that error messages should be "in plain english".... and well, I feel that the error messages in Access could are a lil cryptic, atleast for my non-English speaking userbase.

• @ammoQ said:

@nonDev said:
So basicly you are trying to parse the number out of string?

nonDev

I don't think he got your hint for int32.TryParse() ...

Cool! I wasnt aware of such a method. A little research (http://msdn2.microsoft.com/en-us/library/f02979c7.aspx) tells me that they added this in .NET 2 (I am still using 1.1)

Thanks for the info.

• This is one of the reasons I create my own textbox controls for numerical values.  I create a usercontrol that inherits from TextBox.  I then add code into the KeyPress Event and cancel any key presses that are not valid, essentially only allowing numbers and backspaces/deletes.  It still no substitute for validation later, but why allow an end-user to enter "Bob" in a numerical field in the first place?

• @Nandurius said:

Suppose there was such a thing:

public static boolean isInt(String s) {
try {
Integer.parseInt(s);
return true;
}catch( Exception e) {
return false;
}
}

Would it do you any good? You would STILL have to write:

int i;
if(isInt(s)) {
i = Integer.parseInt(s); // REQUIRES A TRY block.
}

The altenative would be to write a function that returns the integer right away, and write
i = getInt(s);

But now what do you do when it's not a valid number? you could return 0, or -1, but those may be actually the value of the string. So the only non-result you can return is to throw an exception..

See the pattern?

Of course, you can write a function that will try to parse a string as an Integer, Float, Double, Hex, Binary, anything.. That way you can limit most of the try blocks to the inside of that function..

Depending on the application, you can come up with a function that sets a default value, something like what would be used when reading a config file.

int getSetting(String value, int default) {
try { return Integer.parseInt(value); }
catch(Exception e){ return default; }
}

now you can write code without littering every other statement with a try/catch block.

So the method returns a magic number and/or the result, what happens if value == default?

Sorry but this is a major WTF

• @lpope187 said:

This is one of the reasons I create my own textbox controls for numerical values.  I create a usercontrol that inherits from TextBox.  I then add code into the KeyPress Event and cancel any key presses that are not valid, essentially only allowing numbers and backspaces/deletes.  It still no substitute for validation later, but why allow an end-user to enter "Bob" in a numerical field in the first place?

hmm, interesting idea. But can you not achieve the same by implementing the "textChanged" event for your TextBox? Like for instance, everytime the user presses a non-numberic key, you can sound a system beep or something.

Infact, if I am not mistaken, you could even use an errorProvider control.

I guess, what I am asking is why you chose to make a seperate control for this specific task? :o

• @codenator said:

So the method returns a magic number and/or the result, what happens if value == default?

Sorry but this is a major WTF

You say you want a red car, so the car dealer gives you a red car.
You say you don't care what color your car is, so the car dealer gives you a car in the standard blue.

So far, you don't think it's a wtf.

Now you want a blue car, and you get the standard blue, and you think that's a wtf?

It's a trivial thing, really. Use the user-supplied value unless it's not available, then use the default value. If they happen to be the same, then what's the problem?

• @GizmoC said:

hmm, interesting idea. But can you not achieve the same by implementing the "textChanged" event for your TextBox? Like for instance, everytime the user presses a non-numberic key, you can sound a system beep or something.

Infact, if I am not mistaken, you could even use an errorProvider control.

I guess, what I am asking is why you chose to make a seperate control for this specific task? :o

Write a class: No additional thought required when you use it.
Stick an event handler on an existing class: You have to do that every time you use it. Also, the error handler would have to know how to remove the invalid characters and return the field to it's previous (valid) state. When ignoring the keys to begin with, you never have invalid data in the field.

Of course, I think that would cause other problems.
* You can probably rightclick the field or press ctrl+v or shift-ins and paste or drag&drop any text you wish into it.
* If you leave number validation to the libraries, they may handle non-english characters better. I don't know how Japanese or Chinese numbers look like, but I imagine it's a bit of a unicode nightmare

• Well, you can always use a regex to validate the value.
In Java:

public static final Pattern INTEGER_PATTERN = Pattern.compile("^\d+\$");

public static boolean isInteger(String string) {
return INTEGER_PATTERN.matcher(string).matches();
}

• @Nandurius said:

* You can probably rightclick the field or press ctrl+v or shift-ins and paste or drag&drop any text you wish into it.

Well spotted

* If you leave number validation to the libraries, they may handle non-english characters better. I don't know how Japanese or Chinese numbers look like, but I imagine it's a bit of a unicode nightmare

By looking at japanese video games, it seems their digits look like that:
0 1 2 3 4 5 6 7 8 9

• @Nandurius said:

@GizmoC said:
hmm, interesting idea. But can you not achieve the same by implementing the "textChanged" event for your TextBox? Like for instance, everytime the user presses a non-numberic key, you can sound a system beep or something.

Infact, if I am not mistaken, you could even use an errorProvider control.

I guess, what I am asking is why you chose to make a seperate control for this specific task? :o

Write a class: No additional thought required when you use it.
Stick an event handler on an existing class: You have to do that every time you use it. Also, the error handler would have to know how to remove the invalid characters and return the field to it's previous (valid) state. When ignoring the keys to begin with, you never have invalid data in the field.

Of course, I think that would cause other problems.
* You can probably rightclick the field or press ctrl+v or shift-ins and paste or drag&drop any text you wish into it.
* If you leave number validation to the libraries, they may handle non-english characters better. I don't know how Japanese or Chinese numbers look like, but I imagine it's a bit of a unicode nightmare

I chose to extend a user control since it is easier in the long run to just to drag the "NumericTextbox" onto the form.  No monkeying around with the control's eventhandlers on the form/container.  The easier method is to buy a commercial control - I personally prefer ComponentOne's.  As Nandurius noted, it's better to restrict invalid data closest to the original input point, which in this case is the UI.

Nandurius also noted that there are problems with the method I described and is correct that the shortcuts (control-v, right-click -> paste) could still allow bad data in.  To be honest, I didn't fully explain all the code required, but rather pointed you to an approach that I thought was useful.  It gets very interesting when you check whether or not to allow the "-" or "." keys to go through or not.  In the case of shortcuts, You either need to disable them or code for those events.

It's still best practice to have validation at many levels of the application.  Validate input multiple places (UI, data access layer, database) and your application will be much more robust and accurate in the long run. And in terms of numeric validation, I would guess the most complicated part is the thousands & decimal separators. In the US we use "," for thousands and "." for decimal.  Other countries reverse that.  I could be wrong, but I don't think too many countries use numbering systems different from the standard decimal (0 - 9).

• @Nandurius said:

@codenator said:
So the method returns a magic number and/or the result, what happens if value == default?

Sorry but this is a major WTF

You say you want a red car, so the car dealer gives you a red car.
You say you don't care what color your car is, so the car dealer gives you a car in the standard blue.

So far, you don't think it's a wtf.

Now you want a blue car, and you get the standard blue, and you think that's a wtf?

It's a trivial thing, really. Use the user-supplied value unless it's not available, then use the default value. If they happen to be the same, then what's the problem?

What?!

If you are going to dole out coding advice on WTF forum make sure you know WTF you are talking about. Isn't this the forum that says the one place you'd hope you didn't get a WTF to your problem?

Write me some client code that exercises your method....smartarse.

if you wrote that in in an interview I'd askthe same question, if you gave me the answer above I'd mark your file as No Hire permanently.

You obviously have no idea since your goal seems to be removing the language construct of exceptions since you have no clue I thought I'd help you understand what a bad interface your method has and why magic numbers are bad.

• @codenator said:

What?!

If you are going to dole out coding advice on WTF forum make sure you know WTF you are talking about. Isn't this the forum that says the one place you'd hope you didn't get a WTF to your problem?

Write me some client code that exercises your method....smartarse.

if you wrote that in in an interview I'd askthe same question, if you gave me the answer above I'd mark your file as No Hire permanently.

You obviously have no idea since your goal seems to be removing the language construct of exceptions since you have no clue I thought I'd help you understand what a bad interface your method has and why magic numbers are bad.

I assume you're referring to the following code block:

@Nandurius said:

`<font size="4">int getSetting(String value, int default) {    try { return Integer.parseInt(value); }    catch(Exception e){ return default; }}</font>`

If you look at the function name (emphasis mine), I don't think the approach is misguided.  If you persist a setting in a config file/registry/database and it becomes corrupted, why wouldn't you set it back to the default?  If the application originally sets the max number of items to display to 20, you change it to 50 and it gets saved, but somehow the configuration gets corrupted such that it is now "Foobar", I don't think it is a poor design to set it back to 20 the next time the app starts up. It also protects against the possibility that the user specific configuration doesn't exist at all.

• @lpope187 said:

@codenator said:

What?!

If you are going to dole out coding advice on WTF forum make sure you know WTF you are talking about. Isn't this the forum that says the one place you'd hope you didn't get a WTF to your problem?

Write me some client code that exercises your method....smartarse.

if you wrote that in in an interview I'd askthe same question, if you gave me the answer above I'd mark your file as No Hire permanently.

You obviously have no idea since your goal seems to be removing the language construct of exceptions since you have no clue I thought I'd help you understand what a bad interface your method has and why magic numbers are bad.

I assume you're referring to the following code block:

@Nandurius said:
`<FONT size=4>int getSetting(String value, int default) {    try { return Integer.parseInt(value); }    catch(Exception e){ return default; }}</FONT>`

If you look at the function name (emphasis mine), I don't think the approach is misguided.  If you persist a setting in a config file/registry/database and it becomes corrupted, why wouldn't you set it back to the default?  If the application originally sets the max number of items to display to 20, you change it to 50 and it gets saved, but somehow the configuration gets corrupted such that it is now "Foobar", I don't think it is a poor design to set it back to 20 the next time the app starts up. It also protects against the possibility that the user specific configuration doesn't exist at all.

Wrong! Definetly no hire then!! why pass the default only to have it returned in the error case?? why does the method return two things? the result or a magic number indicating parse failure or is it the number? or is it parse failure?. You still haven't written and real world example code to exercise this method in a useful way that I can't poke holes thru.

You ever write a method that passes in and maybe returns a magic number and/or a result you have no idea how to design the most simple of methods. You will never work in my company.

This is a great interview question and one I plan to adopt to weed out those who think they are clever from those who actually know how to program.

• @codenator said:

Wrong! Definetly no hire then!! why pass the default only to have it returned in the error case??
why does the method return two things? the result or a magic number indicating parse failure or is it the number? or is it parse failure?. You still haven't written and real world example code to exercise this method in a useful way that I can't poke holes thru.

I think you don't understand the purpose of this function. The default value is not a magic value that indicates a parse value, but as the name says, a sensible default value the program can work with. Since the default value is not "magic", it's absolutely possible that the function returs this value but not from the default, but from successfully parsing the string. Therefore, it would not be a good idea to use this as indication that a parse error happened.
Of course it's questionable if the program should silently ignore the error, but that depends on the requirements. For example, most web browsers silently ignore malformed HTML.

• @ammoQ said:

I think you don't understand the purpose of this function. The default value is not a magic value that indicates a parse value, but as the name says, a sensible default value the program can work with. Since the default value is not "magic", it's absolutely possible that the function returs this value but not from the default, but from successfully parsing the string. Therefore, it would not be a good idea to use this as indication that a parse error happened.
Of course it's questionable if the program should silently ignore the error, but that depends on the requirements. For example, most web browsers silently ignore malformed HTML.

Those were exactly my intentions. Sometimes a program can just continue on when an incorrect value was encountered. When you're entering personal data, it may be rude to do so, but for configuration settings the user generally really doesn't care.

Since the exact purpose of the validation wasn't clear yet at the time that I posted the suggestion, that's also common place for input validation.

Since you can't seem to figure out how to use this, let me show you:

public void initializeGui(....) {
SomeMap map = getConfigSettingsFromFile();

Rectangle r = new Rectangle();
r.x = getSetting(map.get("windowPositionX", 0);
r.y = getSetting(map.get("windowPositionY", 0);
r.width = getSetting(map.get("windowWidth", 500);
r.height = getSetting(map.get("windowHeight", 650);

mywindow.resize( r );
}

This lets you easily write code that assigns sensible values to your fields. When the config file doesn't have a value for windowPositionX, or it can't be parse, then you use the default position.

Of course you could inline the fuction 4 times and boost your loc.. maybe that might even satisfy your wtf-hiring standards. Because duplicate code is good, a redudnancy prevents.. failures?

• @Nandurius said:

Sometimes a program can just continue on when an incorrect value was encountered.

WTF? I'm sorry can you repeat that? you're example is talking about a config file that you are just ignoring...your config file...wow!! that's great. Keep on diggin that hole.

Let me get this straight. So your method is designed to cover up config problems and remove the language construct of exceptions? that's great defensive programming, are you the guy who developed the student system shere http://thedailywtf.com/forums/thread/83383.aspx ?

@Nandurius said:

for configuration settings the user generally really doesn't care.

Yeah my users don't care about silly old problems in config files, just program around it, they'll never know that way.

@Nandurius said:

that's also common place for input validation.

really? I'm learing here.

@Nandurius said:

Since you can't seem to figure out how to use this, let me show you:

Pleaase do I'm sure you example is brilliant.

@Nandurius said:

SomeMap map = getConfigSettingsFromFile();

I'm confused why you don't pass default vales or file name to getConfigSettingsFromFile(); since the file may not exist or may be empty and you need default values to fall back on...dont' you? oh wait you've got it covered...that's right...silly me.

@Nandurius said:

This lets you easily write code that assigns sensible values to your fields. When the config file doesn't have a value for windowPositionX, or it can't be parse, then you use the default position.

and just when I couldn't possibly think less of you, you come out with the best quote yet.

@Nandurius said:

a redudnancy prevents.. failures?

Brilliant, well I've learnt my lessson. Back to computer science 101 for me then.

I really think I should stop, you haven't read about designing a method interface for good reuse, exception handling, defensive programming but without you WTF wouldn't have any material to entertain me with.

As long as you don't litter your code with that nasty stupid exception handling code and just program away silly problems with bad input data we'll all be safe and happy.

• "Let me get this straight. So your method is designed to cover up config
problems and remove the language construct of exceptions?"

Where does it remove the exception? It refactors the exception handling into a separate function, so that you do not have to cover each line of code in a try/catch block. You know, taking code that is similar and putting it into a parametrized method? It's been around for a few years.. I'm surprised you haven't run into it yet.

This is called refactoring, and if you wish  to learn more, I can recommend the book by Martin Fowler.

Also, since your imagination and ability of reading pseudo code is this lacking I will provide you with, free of charge, another line in my imaginary function.
(Note: the "getConfigSettingsFromFile" is used to suggest appropriate code to do that functionality. As that is not part of the discussion, I didn't think anyone would care as to how it would be implemented in an actual application. But you seem to like everything extra-verbose!)

`int getSetting(String value, int default) {    try { return Integer.parseInt(value); }    catch(Exception e){	Logger.log("Invalid configuration value: " + value +", using " + default + " instead.");	return default; 	}}<font face="Arial"><font face="Times New Roman">Isn't that fancy? Just one line, and now it's available everywhere you use that function to begin with. Oh the joys of functional programming.</font></font><font face="Times New Roman">Well, thank you for the insightful replies. It's really been a long time since I've had such an intelligent discussion. You're realling bringing this to new levels :)</font>`

• In java, you can do something like:

boolean isNumber(String in) {
for (int i=0; i<in.length; i++) {
if (in.charAt<'0'||in.charAt>'9') return false;
}
return true;
}

Putting a single character in single quotes is the same as using the ASCII code of that character - the above code checks if the ASCII code of each character in the string is not that of a numeric character.

• @technites said:

If you use the regex/loop approach, you might also want to allow the minus sign.

Yeah, Pattern.compile("^\s*-?\d+\s*\$")
This allows spaces on the sides, too.

• @Nandurius said:

"Let me get this straight. So your method is designed to cover up config problems and remove the language construct of exceptions?"

Where does it remove the exception? It refactors the exception handling into a separate function, so that you do not have to cover each line of code in a try/catch block. You know, taking code that is similar and putting it into a parametrized method? It's been around for a few years.. I'm surprised you haven't run into it yet.

This is called refactoring, and if you wish  to learn more, I can recommend the book by Martin Fowler.

Also, since your imagination and ability of reading pseudo code is this lacking I will provide you with, free of charge, another line in my imaginary function.
(Note: the "getConfigSettingsFromFile" is used to suggest appropriate code to do that functionality. As that is not part of the discussion, I didn't think anyone would care as to how it would be implemented in an actual application. But you seem to like everything extra-verbose!)

`int getSetting(String value, int default) {    try { return Integer.parseInt(value); }    catch(Exception e){	Logger.log("Invalid configuration value: " + value +", using " + default + " instead.");	return default; 	}}<FONT face=Arial><FONT face="Times New Roman">Isn't that fancy? Just one line, and now it's available everywhere you use that function to begin with. Oh the joys of functional programming.</FONT></FONT><FONT face="Times New Roman">Well, thank you for the insightful replies. It's really been a long time since I've had such an intelligent discussion. You're realling bringing this to new levels :)</FONT>`

what you are doing is not refactoring, it's called bad programming, exceptions are there for a reason, and I've seen this before it and I know it's wrong. Why teach someone to remove them

I'd say your first clue is the interface to this method, I'd say it doesn't need your so called improvement at all, in fact I think it's designed well.

Integer.parseInt(value);

It returns one thing, the value as an int or throws a NumberFormatException when you pass it sometign other than a number represented as a string.

Makes sense, what you are doing is removing the exception form the client code, you think this is clever? you think this is a good thing?

Show me one other public Java API that follows your ludicrous example fo passing in a default value to fall back on.

I'd say that's about as good as it gets, if you want to cover up bad values in your config file go right ahead. That is the most idiotic thing I've ever heard, you have no idea how to code at all do you. Do you just cut and paste all day?

• @codenator said:

what you are doing is not refactoring, it's called bad programming, exceptions are there for a reason, and I've seen this before it and I know it's wrong. Why teach someone to remove them

Those exceptions are not "removed". They are handled properly, because that's the purpose of the function: Try to parse the string; it this doesn't work out, return the specified default value. Maybe in your opinion every exception should be bubbled up to every method on the call stack, until the program eventually crashes, but that is not necessarily good programming. In contrast, I would even call it bad design. At some level of abstraction, the calling method simply doesn't (and shouldn't) care anymore what exactly happened down there; all it has to know is whether or not the operation was successfull. In many cases, not even that.

I'd say your first clue is the interface to this method, I'd say it doesn't need your so called improvement at all, in fact I think it's designed well.

Integer.parseInt(value);

It returns one thing, the value as an int or throws a NumberFormatException when you pass it sometign other than a number represented as a string.

Makes sense, what you are doing is removing the exception form the client code, you think this is clever? you think this is a good thing?

In some cases, it's the right thing to do. Do you think you know every possible specification in the world?

Show me one other public Java API that follows your ludicrous example fo passing in a default value to fall back on.

`System.getProperty`

You should better really learn java before you lean out too far.

I'd say that's about as good as it gets, if you want to cover up bad values in your config file go right ahead. That is the most idiotic thing I've ever heard, you have no idea how to code at all do you. Do you just cut and paste all day?

I'd say you are fresh out of college and think you know everything. Better get some experience, it might help.

• @ammoQ said:

I'd say you are fresh out of college and think you know everything. Better get some experience, it might help.

The part I like most is how he's pretending that he's in charge of hiring. Good lord, he'd have to pay me really well to come in after him and clean up his monkey code.

if( ego > brain) {
throw new StfuException("Error: Unhandled codenator.");
}

• @Nandurius said:

@ammoQ said:
I'd say you are fresh out of college and think you know everything. Better get some experience, it might help.

The part I like most is how he's pretending that he's in charge of hiring. Good lord, he'd have to pay me really well to come in after him and clean up his monkey code.

if( ego > brain) {
throw new StfuException("Error: Unhandled codenator.");
}

I've got about 10 years under my belt with compiler design and public APIs and currently work on the Java compiler team and have designed implemented new featues in the lagnuage for Java 5 including public APIs so if you want to go into battle bring it on. You are both the laughing stock of my company and everyone waits for you replys for a good laugh.

When it comes to API deisgn that what I do all day for work. So you found one example, big deal it's still a bad design. You missed the point in that you are covering up problems and hiding Exceptins from the client code, did you learn OO programming? are you still stuck in C procedural thinking?

I stand by my beliefs because my experience is telling me that it is a poorly designed method, there's a lot of reading a learning you need to do.

I am in charge of hiring at my company at least, and you wouldn't pass an interview, I think you should not be handing out bad coding practices to beginners.

Let's hope I never have to use one of your buggy applications.

• @Nandurius said:

The part I like most is how he's pretending that he's in charge of hiring.

Might be actually true, but means little. The first programmer is likely involved in the decision when a second programmer should be hired. When I was interviewed for my first job, the programmer who asked me the technical questions (to check my skills) was 25. She was hardly longer than one year in that company then, fresh out of the university.

• @ammoQ said:

@Nandurius said:

The part I like most is how he's pretending that he's in charge of hiring.

Might be actually true, but means little. The first programmer is likely involved in the decision when a second programmer should be hired. When I was interviewed for my first job, the programmer who asked me the technical questions (to check my skills) was 25. She was hardly longer than one year in that company then, fresh out of the university.

Ah you sound like an old dog who can't learn new tricks, I bet she learnt good method design and OO.

So what if she's one year out of college, I've hired them and they can code rings around the old dogs at times, other times they don't get it at all, like you, and I don't hire them. Some can learn then come back agin in 12 months to try again, other can't learn, like you and we mark them permanently as no hire.

• @codenator said:

've got about 10 years under my belt with compiler design and public APIs and currently work on the Java compiler team and have designed implemented new featues in the lagnuage for Java 5 including public APIs so if you want to go into battle bring it on. You are both the laughing stock of my company and everyone waits for you replys for a good laugh.

When it comes to API deisgn that what I do all day for work. So you found one example, big deal it's still a bad design. You missed the point in that you are covering up problems and hiding Exceptins from the client code, did you learn OO programming? are you still stuck in C procedural thinking?

I stand by my beliefs because my experience is telling me that it is a poorly designed method, there's a lot of reading a learning you need to do.

I am in charge of hiring at my company at least, and you wouldn't pass an interview, I think you should not be handing out bad coding practices to beginners.

Let's hope I never have to use one of your buggy applications.

Sorry boy, the laugh is on you. If you were really involved with building java compilers and stuff, how comes you don't know System.getProperty? This is really one of the most basic APIs.
(BTW, it isn't bad at all - just pass null as the second parameter to find out whether or not a specific key exists)
"Hiding exceptions from the client code" - I'd call that abstraction. If the client needs to know that an exception happened, it simply should not use that specific method. This method is for clients that need a default value in this case. It's a convenience method for client code that would do nothing more than that in case of an exception.

• @codenator said:

Ah you sound like an old dog who can't learn new tricks, I bet she learnt good method design and OO.

So what if she's one year out of college, I've hired them and they can code rings around the old dogs at times, other times they don't get it at all, like you, and I don't hire them. Some can learn then come back agin in 12 months to try again, other can't learn, like you and we mark them permanently as no hire.

Actually she was very capable, though the program we were working on was written in C, so I can say nothing at all about her OO skills. (I lost contact with her when we both left the company after half a year or so).  Fortunately, I'm not in a situation where I would ever have to apply for a job at a company where people like you are hiring - or even hired.

• @ammoQ said:

@codenator said:

've got about 10 years under my belt with compiler design and public APIs and currently work on the Java compiler team and have designed implemented new featues in the lagnuage for Java 5 including public APIs so if you want to go into battle bring it on. You are both the laughing stock of my company and everyone waits for you replys for a good laugh.

When it comes to API deisgn that what I do all day for work. So you found one example, big deal it's still a bad design. You missed the point in that you are covering up problems and hiding Exceptins from the client code, did you learn OO programming? are you still stuck in C procedural thinking?

I stand by my beliefs because my experience is telling me that it is a poorly designed method, there's a lot of reading a learning you need to do.

I am in charge of hiring at my company at least, and you wouldn't pass an interview, I think you should not be handing out bad coding practices to beginners.

Let's hope I never have to use one of your buggy applications.

Sorry boy, the laugh is on you. If you were really involved with building java compilers and stuff, how comes you don't know System.getProperty? This is really one of the most basic APIs.
(BTW, it isn't bad at all - just pass null as the second parameter to find out whether or not a specific key exists)
"Hiding exceptions from the client code" - I'd call that abstraction. If the client needs to know that an exception happened, it simply should not use that specific method. This method is for clients that need a default value in this case. It's a convenience method for client code that would do nothing more than that in case of an exception.

Those type of convience methods breed bad coding practices and hard to find bugs...but you knew that already

• @ammoQ said:

@codenator said:

Ah you sound like an old dog who can't learn new tricks, I bet she learnt good method design and OO.

So what if she's one year out of college, I've hired them and they can code rings around the old dogs at times, other times they don't get it at all, like you, and I don't hire them. Some can learn then come back agin in 12 months to try again, other can't learn, like you and we mark them permanently as no hire.

Actually she was very capable, though the program we were working on was written in C, so I can say nothing at all about her OO skills. (I lost contact with her when we both left the company after half a year or so).  Fortunately, I'm not in a situation where I would ever have to apply for a job at a company where people like you are hiring - or even hired.

I doubt you'd pass the phone screen given by HR wher ethey read Java coding questions off a piece of paper, just how many people use your code? millions? billions? 100 frustrated clients who can't understand why random bugs pop up every now and then? don't move to San Fran or Seattle those companies aren't interested in people like you, best stya in the good old south where you'll feel smart and superior

• @codenator said:

Those type of convience methods breed bad coding practices and hard to find bugs...but you knew that already

Depends on who is using it and when. If the client code would otherwise look like that
`try {    x=y(z);}catch (FoobarException e) {    x=someValue;}`

it's ok to use
`x=tryY(z, someValue);`

• @codenator said:

I doubt you'd pass the phone screen given by HR wher ethey read Java coding questions off a piece of paper, just how many people use your code? millions? billions? 100 frustrated clients who can't understand why random bugs pop up every now and then? don't move to San Fran or Seattle those companies aren't interested in people like you, best stya in the good old south where you'll feel smart and superior

Don't worry, I live in Vienna, Austria and that's very very far from the San Francisco area, and I don't feel like moving there. Especially if that means I might meet people like you there. BTW, there is a big difference between "random bugs popping up every now and then" and a program that, for one reason or another, uses default values when the config file (or the environment variables or whatever) is not in shape. Guess what the difference is.

• @ammoQ said:

@codenator said:

what you are doing is not refactoring, it's called bad programming, exceptions are there for a reason, and I've seen this before it and I know it's wrong. Why teach someone to remove them

Those exceptions are not "removed". They are handled properly, because that's the purpose of the function: Try to parse the string; it this doesn't work out, return the specified default value. Maybe in your opinion every exception should be bubbled up to every method on the call stack, until the program eventually crashes, but that is not necessarily good programming. In contrast, I would even call it bad design. At some level of abstraction, the calling method simply doesn't (and shouldn't) care anymore what exactly happened down there; all it has to know is whether or not the operation was successfull. In many cases, not even that.

This whole conversation has everything to do with at what point does an error condition get bubbled up to the caller.  Some, like myself, think that if the error can be safely handled locally then it is appropriate to do so.  There is no harm in utilizing a default value for an inconsequential config setting provided there is some mechanism to handle and/or correct the error. In production code, I would perhaps implement some type of parse counter for non-critical settings.  Should the counter reach some threshold, then I would bubble up an error to the caller.

@ammoQ said:
@codenator said:

Show me one other public Java API that follows your ludicrous example fo passing in a default value to fall back on.

`System.getProperty`

You should better really learn java before you lean out too far.

Java isn't the only API that has this type of functionality either.  The Windows API has two functions with a similiar behavior, GetProfileString and GetPrivateProfileString.  They deal with reading config settings from the registry or ini file respectively and in both cases you can pass in a default value should the setting not exist.

Another example is .Net 2.0's default handling of the My.Settings namespace.  By default if the value isn't specified in the app.config, it will retrieve the default value specified in the getter's attributes.  The only difference is in this case, you can disable that behavior.

• @codenator said:

I doubt you'd pass the phone screen given by HR wher ethey read Java coding questions off a piece of paper, just how many people use your code? millions? billions? 100 frustrated clients who can't understand why random bugs pop up every now and then? don't move to San Fran or Seattle those companies aren't interested in people like you, best stya in the good old south where you'll feel smart and superior

Yay. Another pompous display of sheer arrogance, ignorance and nonsense. You just won't give up trying to find a point to make, no matter how many unrelated (and, dare I say, fictitious) things you have to bring up.

If I pretend that you're right, will you please shut up? Is that how your "API design" works, too? Do you argue nonsensical points with everyone until they decide to just leave you to yourself, and then go do the right thing anyway?

Well, again, thanks for your 'insight.'

P.S.: Are you familiar with the reflection API? Why don't you go take a good look at yourself.
best stya in the good old south where you'll feel smart and superior

• @codenator said:

@Nandurius said:

if( ego > brain) {
throw new StfuException("Error: Unhandled codenator.");
}

I've got about 10 years under my belt with compiler design and public APIs and currently work on the Java compiler team and have designed implemented new featues in the lagnuage for Java 5 including public APIs so if you want to go into battle bring it on. You are both the laughing stock of my company and everyone waits for you replys for a good laugh.

Hahaha. WTF-in-action

• @lpope187 said:

Java isn't the only API that has this type of functionality either.  The Windows API has two functions with a similiar behavior, GetProfileString and GetPrivateProfileString.  They deal with reading config settings from the registry or ini file respectively and in both cases you can pass in a default value should the setting not exist.

Another example is .Net 2.0's default handling of the My.Settings namespace.  By default if the value isn't specified in the app.config, it will retrieve the default value specified in the getter's attributes.  The only difference is in this case, you can disable that behavior.

Another example that comes to my mind are internationalisation/localisation APIs where the original (in many cases: English) text is both the key and the default value for the translation into the user's native language.

• @Nandurius said:

@codenator said:

I've got about 10 years under my belt with compiler design and public APIs and currently work on the Java compiler team and have designed implemented new featues in the lagnuage for Java 5 including public APIs so if you want to go into battle bring it on. You are both the laughing stock of my company and everyone waits for you replys for a good laugh.

Hahaha. WTF-in-action

You should not laugh about him. In most cases there is a unfunny reason when the whole company (or, at least, the whole team) has to work on sundays. But well, I don't think the company that brought us Java has too many reasons to laugh right now, so if we (for some rather strange reason) amuse them, we should grant them the laugh. The situation of said company is sad enough.

• @Thalagyrt said:

@codenator said:
@ammoQ said:
@codenator said:

Ah you sound like an old dog who can't learn new tricks, I bet she learnt good method design and OO.

So what if she's one year out of college, I've hired them and they can code rings around the old dogs at times, other times they don't get it at all, like you, and I don't hire them. Some can learn then come back agin in 12 months to try again, other can't learn, like you and we mark them permanently as no hire.

Actually she was very capable, though the program we were working on was written in C, so I can say nothing at all about her OO skills. (I lost contact with her when we both left the company after half a year or so).  Fortunately, I'm not in a situation where I would ever have to apply for a job at a company where people like you are hiring - or even hired.

I doubt you'd pass the phone screen given by HR wher ethey read Java coding questions off a piece of paper, just how many people use your code? millions? billions? 100 frustrated clients who can't understand why random bugs pop up every now and then? don't move to San Fran or Seattle those companies aren't interested in people like you, best stya in the good old south where you'll feel smart and superior

Random bugs occur when people like you try to read in a config file that has no value for a necessary parameter, and just leave that as null instead of whatever an appropriate default value is. The real WTF is that you think you know WTF you're doing.

Let's just fast-forward to everyone calling everyone else a scumbag!

• @Thalagyrt said:

Random bugs occur when people like you try to read in a config file that has no value for a necessary parameter, and just leave that as null instead of whatever an appropriate default value is. The real WTF is that you think you know WTF you're doing.

as opposed to throwing an exception when a config value that should be a number is unable to be parsed as one?

The example given is lame, you would get drilled at my company if you wrote that crap.

Let's get back to the original issue, parsing a String, the advice given out on how to parse a String as a number, the example method given was a major WTF, you shouldn't be giving out that advice if you don't know WTF you are talking about.

I'm starting to think most people here are idiots, am I the only one who thinks Parsing a String as a int and covering up the exception is bad thing?

• @ammoQ said:

@Nandurius said:
@codenator said:

I've got about 10 years under my belt with compiler design and public APIs and currently work on the Java compiler team and have designed implemented new featues in the lagnuage for Java 5 including public APIs so if you want to go into battle bring it on. You are both the laughing stock of my company and everyone waits for you replys for a good laugh.

Hahaha. WTF-in-action

You should not laugh about him. In most cases there is a unfunny reason when the whole company (or, at least, the whole team) has to work on sundays. But well, I don't think the company that brought us Java has too many reasons to laugh right now, so if we (for some rather strange reason) amuse them, we should grant them the laugh. The situation of said company is sad enough.

So what language do you use then to earn a living? huh? You use Java, cna't do it well but are the firs to criticise it, lame... You sound like a bandwagon loser.

• @Thalagyrt said:

@codenator said:
@ammoQ said:
@codenator said:

Ah you sound like an old dog who can't learn new tricks, I bet she learnt good method design and OO.

So what if she's one year out of college, I've hired them and they can code rings around the old dogs at times, other times they don't get it at all, like you, and I don't hire them. Some can learn then come back agin in 12 months to try again, other can't learn, like you and we mark them permanently as no hire.

Actually she was very capable, though the program we were working on was written in C, so I can say nothing at all about her OO skills. (I lost contact with her when we both left the company after half a year or so).  Fortunately, I'm not in a situation where I would ever have to apply for a job at a company where people like you are hiring - or even hired.

I doubt you'd pass the phone screen given by HR wher ethey read Java coding questions off a piece of paper, just how many people use your code? millions? billions? 100 frustrated clients who can't understand why random bugs pop up every now and then? don't move to San Fran or Seattle those companies aren't interested in people like you, best stya in the good old south where you'll feel smart and superior

Random bugs occur when people like you try to read in a config file that has no value for a necessary parameter, and just leave that as null instead of whatever an appropriate default value is. The real WTF is that you think you know WTF you're doing.

Who said I'd make it null? Who said I was working on Sunday? you're a idiot. Irrational.

• @codenator said:

I'm starting to think most people here are idiots, am I the only one who thinks Parsing a String as a int and covering up the exception is bad thing?

I for one belive handling exceptions at the lowest possible level is a good thing. This is what OOP is all about. How exceptions are handled depends on the nature and purpose of your software. Handling can be many things in different contexts.
Eg: I'd rather see an RPG flying through a wall the to have my FPS crash just because some value was divided by zero. On the other hand, I'd rather see bells and whistles go off on a hart-rate monitor then it defaulting to normal sinus rhythm.
Context is important and handling exceptions is not the same as throwing them.

• @codenator said:

So what language do you use then to earn a living? huh?

PL/SQL

You use Java, cna't do it well but are the firs to criticise it, lame... You sound like a bandwagon loser.

Java is less important for me. Maybe we will replace the Java parts of our software with .net one fine day.

• @codenator said:

I've got about 10 years under my belt with compiler design and public APIs and currently work on the Java compiler team and have designed implemented new featues in the lagnuage for Java 5 including public APIs so if you want to go into battle bring it on. You are both the laughing stock of my company and everyone waits for you replys for a good laugh.

When it comes to API deisgn that what I do all day for work. So you found one example, big deal it's still a bad design. You missed the point in that you are covering up problems and hiding Exceptins from the client code, did you learn OO programming? are you still stuck in C procedural thinking?

I stand by my beliefs because my experience is telling me that it is a poorly designed method, there's a lot of reading a learning you need to do.

I am in charge of hiring at my company at least, and you wouldn't pass an interview, I think you should not be handing out bad coding practices to beginners.

Let's hope I never have to use one of your buggy applications.

So you have all that experience and you still don't understand that there's a reason for the catch keyword? Isn't handling exceptions exactly what it was designed for? Surely you know - after all,, you have all that vast superior knowledge, don't you?

You're a total idiot. Crawl back up in the cave you somehow stumbled out of, so we don't have to waste our time scrolling past all of your useless noise.

• @ammoQ said:

@codenator said:

So what language do you use then to earn a living? huh?

PL/SQL

You use Java, cna't do it well but are the firs to criticise it, lame... You sound like a bandwagon loser.

Java is less important for me. Maybe we will replace the Java parts of our software with .net one fine day.

PL/SQL oh my god!!!

That is the biggest WTF in hiistory no wonder you are passing magic numbers and giving out bum Java coding advice. Ha ha aha ahahaha

• @Thalagyrt said:

@KenW said:
@codenator said:

I've got about 10 years under my belt with compiler design and public APIs and currently work on the Java compiler team and have designed implemented new featues in the lagnuage for Java 5 including public APIs so if you want to go into battle bring it on. You are both the laughing stock of my company and everyone waits for you replys for a good laugh.

When it comes to API deisgn that what I do all day for work. So you found one example, big deal it's still a bad design. You missed the point in that you are covering up problems and hiding Exceptins from the client code, did you learn OO programming? are you still stuck in C procedural thinking?

I stand by my beliefs because my experience is telling me that it is a poorly designed method, there's a lot of reading a learning you need to do.

I am in charge of hiring at my company at least, and you wouldn't pass an interview, I think you should not be handing out bad coding practices to beginners.

Let's hope I never have to use one of your buggy applications.

So you have all that experience and you still don't understand that there's a reason for the catch keyword? Isn't handling exceptions exactly what it was designed for? Surely you know - after all,, you have all that vast superior knowledge, don't you?

You're a total idiot. Crawl back up in the cave you somehow stumbled out of, so we don't have to waste our time scrolling past all of your useless noise.

I just love that he thinks having default values is a bad idea. I mean, if your config file gets corrupted, the application should just crash, and not recover gracefully by having default values, right? Looks like he backpedaled on that one pretty fast. The guy's a class A idiot, sounds like some PHB who thinks he knows everything but really knows nothing at all.

I'm sorry I'm not backpedaling at all, if your config file is corrupted wouldn't you want to know about it?? let's say it was an important variable that if you used the default it gave un-expected results, how do you track that bug down genius?

Do you know about defensive programming, you know some problems should bublle to the surface so they ca be fixed, right?

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.