• P (unregistered)

    View all -1 comments

  • bvs23bkv33 (unregistered)

    "we have rich, well-supported, well-documented features" - sprintf and sscanf lol

  • Footer (unregistered)

    Your absolute positioning on the footer is broken in firefox

  • (nodebb)

    This snippet is stupid of course but to be fair, checking for empty string prevents exception throwing and catching, and depending on how expensive that is, this might be a tiny optimization. I'll let people who know Java more than me opine on whether what I said holds water.

  • Ulysses (unregistered)

    It would make a difference for bulk imports of low-quality data. That said, I still chuckle at Java kids who devote brain cycles to perf. That horse has long since bolted from the stable.

  • (nodebb) in reply to Ulysses

    I disagree with the attitude that performance doesn't matter - it does. Whether this integer parsing is a good example is debatable, but slow applications are frequently the result of many programmers ignoring performance. It might look like a micro optimization in the context of a specific function, but things add up quickly.

  • Ulysses (unregistered)

    What you replied to barely resembles what I wrote. Of course perf matters, and it's funny to build on top of Java and then think of lower-level optimizations. Of course things add up, and I started with a good example of such.

  • Jaime (unregistered)

    Although performance matters... fast but incorrect code is always bad code. Bypassing the exception to return -1 is a horrible idea.

  • LCrawford (unregistered)

    This is known as the VBA-Emulating Semi Signum function pattern. The VBA because old Visual Basic number conversion code tends not to throw an exception but give a 0 result - modified here to return a -1. Semi-Signum because the lower half of the number line was compressed to return -1.

  • Brian (unregistered)

    Too bad this is Java (or at least I assume so from previous comments). If it were C#, she could just replace this whole mess with the handy TryParse() function.

  • dpm (unregistered) in reply to Brian

    she could just replace this whole mess with the handy TryParse() function

    Au contraire; the callers still expect an int back, so what good does calling TryParse() do? She'd still need to test it and return something.

  • ooOOooGa (unregistered) in reply to Ulysses

    Bulk import of dirty data is one of the few good examples of needing to optimize exception handling.

    Most of the time, if an exception gets thrown (when not using exceptions for flow control - which is its own WTF) the system is going to either crash and burn (hopefully after writing some log entries), or is going to abort everything and return (sheepishly|accusingly|silently) to the UI for the user to decide what to do from there. Neither of those needs to be done at highly optimized speeds. It just needs to be done fast enough that the user doesn't get bored waiting for it.

  • Vicki (unregistered)

    The title of the article confused me at first - an intentional error would be rather more of a WTF than an unintentional one. But then I saw that, although the page itself displays the title in uppercase, and the URL is in lowercase, my browser's title bar gives away the joke - it's meant to be capitalised as "UnINTentional Errors".

  • (nodebb) in reply to Mr. TA

    Mr. TA,

    Exception handling is indeed expensive in Java. It also prevents certain JVM optimizations for the code inside the try block.

    As a general rule, using exception handling for control flow is not a best practice in Java (and probably not for other languages). So using a good well written string utility class like Apache Commons Lang StringUtils is a valid and desirable practice to short circuit trying to format a string that will throw an exception. StringUtils.isNumeric() would be better than a more general purpose null/empty check, although it does not handle leading sign chars. NumberUtils might be better to use.

    Addendum 2019-09-04 13:37: I meant to say trying to parse a string - not format it.

  • Rob (unregistered) in reply to dpm

    C#'s TryParseInt doesn't return the int, it passes it as an out parameter. It returns a boolean that indicates success or not. If true, the out parameter contains the parsed value. It's up to the caller to determine what to do if the method returns false.

  • Rob (unregistered) in reply to Developer_Dude

    One of the problems with a check like StringUtils.isNumeric is that it leads to going through the String twice upon success - once for the check, then once for the parsing. I prefer something like C#'s TryParseInt. I've even written something myself (https://github.com/robtimus/try-parse) that returns an OptionalInt - empty if parsing fails, otherwise an OptionalInt with the parsed number.

  • Naomi (unregistered) in reply to Rob

    I was just on the verge of writing an implementation of this myself. Your timing is exemplary :P

  • Steve (unregistered)

    So parsing junk data ... ... ...

    I would just leech off someone elses stuff. Plenty of bad things in the world. Dumping my work on them to keep them busy is a scarcity today.

    If I needed an integer, I would demand integer input. Not string. Not number. If they messed up and I changed it to what it should be, lets say the empirical record and a brief skim of your health records, hows that my problem?

  • Olivier (unregistered) in reply to Steve

    Until you are assigned the work of actually parsing and cleaning the dirty data...

    I tend to like the type of architecture that adds a cleaning layer, independent from the input layer and from the data processing layer.

  • machren (unregistered)

    Sorry to mention this, but the lack of circumstances may cause this not to be a WTF. If this is used in context of a single dialog, reading single, always positive input, then the validation is effectively valid. It just combines both type conversion and validation into a single function. Not so uncommon case.

    If, on the other hand, the function is used more generally, then it really is a WTF, as mentioned in the article.

  • Old Timer (unregistered) in reply to LCrawford

    semi-signum WTF? Old BASIC code returned zero from VAR if the text was not a number. VB code throws an exception if cint() can't convert a number. And using 'true' as a fail code isn't something that a VB programmer would come up with: the whole 'in channel code signalling' paradigm is entirely characteristic of a c programmer, not a BASIC or VB programmer. (BASIC only used in channel error codes when exception handling was turned off, typically for serial I/O).

    BASIC had basic exception handling from the start, before languages like c or Pascal were thought of, and long before c++ was ever dreamed of, for exactly the reason that c++ has exceptions: when you have a meta-program (to handle objects and memory), you can use the meta-program to handle exceptions, rather than crashing the program by throwing exceptions to the OS or Hardware.

    The exception handling in BASIC and VB is basic (doesn't even include named exceptions, no separate definition of try/catch blocks etc) because it was early. Languages like c++ which came later got the benefit of further thought.

  • A programmer (unregistered)

    I am surprised no one brought up the golden rule of optimization: Measure first, optimize second! Readability should be your priority. If you start "optimizing" things off the top of your head, without measuring, you will waste time changing things that don't matter and your code will become a mess.

  • markm (unregistered)

    Perhaps there are reasons for the null/empty string check - slow performance of throwing an exception when masses of data are imported, or a desire to get separate errors for an empty string versus a string that does not begin with a number. But using -1 as an in-channel error signal has been implemented quite badly:

    TRWTF 1: It should be named something like nonNegNumberToIntFormat.

    TRWTF 2: According to Remy, the calling code does not trap -1 or < 0 as an error, so apparently the demi-guru who wrote this mess forgot his own convention.

    Also, if the intention was to distinguish the different possible errors and negative numbers are an error, it's weird to return the same code for empty string and negative number, but throw an exception for "ABC".

    As an old and quite paranoid c programmer, I would either trust the library function (but what does sscanf(value,"%d",&returnValue) do when value is null, empty, or not a number? I'd write some test cases to be sure the library description was accurate.), or I would write a complete check of the input string, with a second channel to return the error code(s). Checks would be for value == null, then for strlen(value) == 0, and finally a loop to skip leading white space and confirm the string started with either a digit or '-' followed by a digit.

  • (nodebb) in reply to markm

    You say nonNegNumberToIntFormat, but from what I see, passing it zero causes the function to return -1, so tryParseStrictlyPositiveInteger() would be a better name.

  • Gnasher729 (unregistered) in reply to Olivier

    A nice example I found: Some poor sod having to process JSON input found that his data contained dress sizes which were usually integers (8, 10, 12 etc. ). Until one dress had size “12-14” as a string :-(

  • x (unregistered) in reply to bvs23bkv33

    or atoi or strtol etc...

  • markm (unregistered) in reply to Gnasher729

    Ouch!

    The method I was proposing would have returned 12 for "12-14". That might be the best way to clean such entries as "size 12-14" for import into a database that didn't expect such complications. Sometimes sizes are letters or names like "small", but if you want to sort the entries and let the user search by approximate size (where size 11 does not come immediately after size 1), you might have to suppress the anomalies and use only integers. OTOH, if you want to flag the anomalies, it needs to check the entire string before trying to convert it.

Leave a comment on “UnINTentional Errors”

Log In or post as a guest

Replying to comment #508010:

« Return to Article