Chubertdev's snippet thread
-
It's even worse than that. People often use .ToString() as defensive coding when something is declared as System.Object, but is supposed to contain a string, so that they don't get a run time exception. In the few cases where the .ToString() isn't a no-op, it returns the class name and is almost never what you want. This pattern turns runtime errors into bad output, which does nothing but make them harder to find.
That reminds me of this Java antipattern:
// foo is a variable of some user-defined reference type; doesn't matter which System.out.println("foo is now " + foo.toString());
Why is this an antipattern? Because it now will fail with a “friendly” uninformative
NullPointerException
whenfoo
happens to benull
. Simply removing the.toString()
will make the code work the same way except for not having that failure mode! (The way string concatenation is implemented does all the right checks to defend against that under the covers. Has done since forever.)I'm not quite sure why people write this. Maybe they expect objects to be converted to strings by some other magical mechanism otherwise that hasn't ever been implemented in any code?
-
Obviously the solution is to have toString or ToString or String be a part of the standard library in an interface that types aren't required to implement. That way, you can't go oBJECT.tOsTrInG and expect it to do something fancy without knowing what your code is supposed to do beforehand.
-
Obviously the solution is to have toString or ToString or String be a part of the standard library in an interface that types aren't required to implement.
That will just change the antipattern to:
bar = ((Stringable)foo).ToString()
-
panic: interface conversion: int is not fmt.Stringer: missing method String goroutine 16 [running]: runtime.panic(0x1110a0, 0x10322160) /tmp/sandbox/go/src/pkg/runtime/panic.c:279 +0x120 main.main() /tmpfs/gosandbox-c71f4918_00afeeaa_014259a4_8337d558_a35316a1/prog.go:8 +0x60 goroutine 19 [runnable]: runfinq() /tmp/sandbox/go/src/pkg/runtime/mgc0.c:2606 runtime.goexit() /tmp/sandbox/go/src/pkg/runtime/proc.c:1445
-
Obviously the solution is to have toString or ToString or String be a part of the standard library in an interface that types aren't required to implement.
In Java, the
toString()
method is defined by the root class. It will be there, and will be used. You can override it if you wish (unlike C++, all method dispatch in Java is dynamic1) but don't need to.1 This is something that the Java language designers got right, and from the beginning. The JITter can convert to static dispatch if it wants, but the lack of BS over what gets to handle the method call — always the object that you have when you're working with instance methods — is worth the minor performance drop in the other cases.
-
-
I don't post in the status thread, but if you'll allow me to hijack your snippet thread, this is frustrating and funny at the same time:
ERROR PricingAdminTests - Test redacted[0: SKU <redacted>] failed with "New price did not increase by $100.00; expected 77300 but received 77300, which is 10000 cents above the old price".
FML
-
curses.... i almost had that SKU to google!
live updaaaaates!
-
haha, not that it probably matters, since the product doesn't cost $773 in production anyway. The test forgot to clean up old price adjustments, so every run the "base" price goes up $100. I'll fix that after I finish this stupid comparison issue.
-
The test forgot to clean up old price adjustments
hmm..... AUTOMATED TEST FAIL!
i've seen that bug far too many times to find it funny.
it's particularly good when one test does that that happens to run before a bunch of others that assume the first test messed it up, and then you add a test that reorders the run (or turn on test order randomization. if your test harness doesn't have this then lobby for it to be added!) and they suddenly all break because the leaked value doesn't happen before they run.
-
Yeah, I've got a step saying "Go back to the admin and delete the new pricing rule", but somehow the click is failing. Stupid Selenium. Or probably stupid IE driver. Or maybe stupid IE. The test isn't ready for deployment yet, mostly because of that. Good thing I'm in demo using a testing client and a test environment.
a bunch of others that assume the first test messed it up
Don't do that :(
The fix was
assertTrue("New price did not increase by $100.00; expected " + expectedPrice + " but received " + newPrice + ", which is " + (newPrice - oldPrice) + " cents above the old price", newPrice.intValue() == expectedPrice.intValue());
Instead of
assertTrue("New price did not increase by $100.00; expected " + expectedPrice + " but received " + newPrice + ", which is " + (newPrice - oldPrice) + " cents above the old price", newPrice == expectedPrice);
I now successfully fail with
12:24:37.669 [main : Internet Explorer 10 ] ERROR PricingAdminTests - Test redacted[0: SKU <redacted>] failed with "Price did not return to previous value; expected 107300 but received 117300".
Because of the stupid not clicking bug
-
Don't do that
i didn't i found it when i added my test and the test harness decided to change the order of execution.
then i turned on order randomization to find all the other instances where that sort of thing had bled through.
there were a lot of them. they did not last long before i stamped them out of existence.
-
hahaha now it crashes because there's a maximum to the number of pricing rules.
My day, ladies and gentlemen.
-
One of these days I need to look into our selenium harness and see if I can run it in an isolated environment instead of the active one, so it's not affected by subsequent runs of itself. The responsible team is all like 'But it reverses everything it does'.
Mostly though I don't care because the parts I work in don't use selenium, and all our other tests already run in isolated (scratch) environments.
-
I kind of want to set up a webdriver server that spins up vagrant images to deliver the browser you want... then we bought a subscription to Sauce Labs instead.
-
newPrice.intValue() == expectedPrice.intValue());
Haha! I expected floating point to be the culprit. Even though you'd multiplied out to use pennies as the base unit.
-
I had originally created a Price object that stored a dollar value and a cents value until my friend gently took me aside and slapped the Enterprise out of me. Then I went back and replaced it with simple Integer number of cents.
-
I had originally created a Price object that stored a dollar value and a cents value until my friend gently took me aside and slapped the Enterprise out of me. Then I went back and replaced it with simple Integer number of cents.
Fixed-point is the way to go for money math, for all practical purposes -- it's what the payment-card backoffice software I worked on as an intern used (and still uses). When done right, it's possible to handle fractions of a cent as well (say, when computing bank card fees).
-
Eh, when the math is always oldprice + $100.00 = newprice.... not much value in changing it again :)
-
hmm..... AUTOMATED TEST FAIL!
I can beat that.
The airline/hotel booking system doesn't have a test environment (or at least, not one that was exposed to us). When I was working on [redacted] we were told not to commit test transactions, or we would be booking real flights/hotels/cars and would have to contact a travel agent to cancel them.
Said system is a huge WTF, too, or at least what I worked on was. Want to book a flight to and from a small city near a major one? Good luck. Want to go from Gainesville, FL, to Macon, GA? Too bad, you'll be flying Gainesville -> Tampa -> Atlanta -> Macon. Want to go to Atlanta from Tampa? You might get routed through Detroit or Denver!
This kind of thing can happen in the regular world, when you're using Orbitz or whatever, but it seemed a lot more prevalent.
-
Even though you'd multiplied out to use pennies as the base unit.
It's kind of interesting to me that nobody uses BCD, which has the advantage it works with any given number of decimal places without having to adjust your multiplier.
ETA: And x86 has builtins for BCD math, too.
-
It's kind of interesting to me that nobody uses BCD, which has the advantage it works with any given number of decimal places without having to adjust your multiplier.
Well, unless you are using an oracle database.
-
Well, unless you are using an oracle database.
Not a supported data type? That just pushes my question back one layer.
-
Not a supported data type? That just pushes my question back one layer.
Oracle's NUMBER type uses BCDs (base-100). If, for whatever reason, you want standard floating point you need to use BINARY_FLOAT or BINARY_DOUBLE.
There's a significant piece on the internal workings in the official docs but I can't be bothered to look it up right now.
-
Oracle's NUMBER type uses BCDs (base-100).
OIC. I interpreted your post in the wrong direction. (Progress, the product I use, doesn't even have a floating-point type: it uses a BCD with IIRC 50 significant figures and 10 decimal places.)
-
ETA
OIC
Are you sponsored by acronym finder or something?
I assume that's "Edited to Add" and "Oh I See".
-
I had originally created a Price object that stored a dollar value and a cents value until my friend gently took me aside and slapped the Enterprise out of me
That's priceless
-
ETA: And x86 has builtins for BCD math, too.
Due to lack of use, deprecated in x32 since Pentium 4, removed in x64.
-
Are you sponsored by acronym finder or something?
There's probably an article on Reader's Digest for you that will help you get up to speed.
Oh, wait, here it is: http://www.cnn.com/2014/12/08/living/internet-acronyms-every-parent-should-know/index.html
-
-