Bug - Fixed Sorting on the restore pane causes Unexpected error/debug

Nice and clean, and I can't make any examples fail.

Things I couldn't figure out how to test but thought about...
If o2class were a String, but o1class wasn't, we'd be in the second case. I don't see any way for that to happen, but I could be wrong. It would be fine if it did, as long as o2val parses as a long (with an extra java.lang.string.toString()...). It would throw a NumberFormatException if o2val wasn't parseable.

If floats or doubles ever become important, I think they end up in the unparseable NFE case, based on trying parseLong on a float in a string.

Given that it passes all my tests, I don't think it needs to be changed.
 
I really did not want to test for every possible class. That way lies madness.

I took advantage of the fact that since we are sorting a table that is displayed the chances of having something that was invalid as numeric string were small. But yeah, I can construct data that might blow things up but I am pretty sure something else would have blown up first in mafia.

I did some quick testing and never actually saw a case where the object classes were different from each other.

If I wanted a robust sorter and insisted on sorting arbitrary objects I would implement a string compare that was numeric, not lexical (09 comes after 1, 100 comes after 2 and so on) and then just sort on whatever toString() returned and be done.

Alternatively I would force each column to have a single object type and the sorter would be simpler. Under some circumstances the compiler would enforce the single object type :-)

But it looks like this might do the trick.
 
Yes, I wasn't objecting, just thinking aloud as a tester to make sure I'd been reasonably thorough.

Also, thank you for your analysis, it's helpful as I try to become a better coder. :)
 
You must log in or register to reply here.
Back
Top