• plis (unregistered)

    Frist

  • dpm (unregistered)

    The "else" after a "return" bothers me almost as much as the not-understanding-boolean-expressions.

  • Cornify (unregistered)

    The worst part of this is using a BigInteger to get an interger value that is only ever 1 or 0. What's wrong with a normal int?

  • Quite (unregistered)

    Don't forget the "int checkStarted = -1" when you know it's going to be overwritten by whatever comes out of the parseInt (which, if it fails, will throw an IllegalArgumentException anyway, IIRC).

    But I'm still lubricating my garments over the use of BigDecimal to hold what is effectively nothing more exciting than a boolean.

  • Screw the sotry of fxing it (unregistered)

    I'm mostly mad over the place where the exception is created. Every time that line is run, a stack trace is created. But performance doesn't bother me unless it is an actual problem in production. What bothers me is that the exception that is caught is never passed into CommonException so the "caused by exception" isn't even provided in the complete stack trace.

  • Andreas (google) in reply to Cornify

    Use a friggin bool!

  • Andreas (google) in reply to Cornify

    Use a friggin bool!

  • Fran (unregistered) in reply to Screw the sotry of fxing it

    I've seen a lot of this "handling error" code:

    try { doSomething(); } catch (DetailedException e) { throw new EmptyUselessExceptionWithoutAnyInformation("Error"); }

  • Friendly_Reminder (unregistered)

    I have seen integers that never hold anything else than either 1 or 0, making me wonder why it wasn't declared as bool in the first place. I also have seen integers being converted to string and then checked with "if(result.Equals("1"))", which is even worse. But I have never seen BigDecimals that only hold 1 or 0 being converted to String, being parsed to int, to ultimately return a bool. Wow.

  • Screw the sotry of fxing it (unregistered) in reply to Friendly_Reminder

    "boolean" is not a valid data type for the Oracle database.

    That is why it is why you don't see it. It would probably be backed as if an integer for performance reasons anyways so fast memory access can occur. As a bit only makes sense in memory if you take 32 Booleans and put them into memory as a bitmask with some sort of logic to handle the mapping to memory. And there in lays the problem. Doing constant looking up and bitmask operations along with a data value to state where in the 32 bits the bit you care about is located and you are looking at some serious overhead for performance. And the memory overhead wouldn't be any better since you need an integer to know where in the bitmask your bit is..

    What is really needed is a hardware memory system for bits that high ends servers can utilize. The problem then is that L1/L2/L3 cache also needs to support this memory type. And processors will need to support a bunch of new operations.

    Now if there were a Boolean type, that would be nice but behind the scenes it would just be an integer anyway.

  • Jerepp (unregistered)

    return checkStarted == 1 ? true : !true;

    There is that better?

  • dorukayhan (unregistered) in reply to Jerepp

    No, it’s not even correct - you forgot FILE_NOT_FOUND. This is obviously the best way:

    if(checkStarted == 1 ? true : false) { return Boolean.valueOf(!Boolean.FALSE.booleanValue()); } else if(checkStarted == 1 ? false : true) { return Boolean.valueOf(!Boolean.TRUE.booleanValue()); } else { return Boolean.valueOf(FILE_NOT_FOUND); // Stupid Java doesn’t provide the significantly more robust Boolean.FILE_NOT_FOUND }

  • What's wrong with a normal Int (unregistered) in reply to Cornify

    Or even, since the values are only ever 0 and 1, a Bit.

  • (nodebb)

    Converting BigDecimal to Integer by any means is error-prone, if the database does not enforce check Startex 0 or 1. It would be better for the code to compare the database value to BigDecimal.ZERO and BigDecimal.ONE.

    Oh, right, he didn't know about those constants, either.

  • MiserableOldGit (unregistered) in reply to What's wrong with a normal Int

    Sadly, due to various DBMS weirdness, bits are a pain in the arse. But a tinyint, or a boolean if you are feeling extravagant, or a nice and surreal char(1) so you can put an F in for FILE_NOT_FOUND ...

  • (nodebb) in reply to MiserableOldGit

    Char? So "T" for true, "F" for false, and "F" for FILE_NOT_FOUND? That won't end well.

  • doubting_poster (unregistered)

    the mysql performance recommendation for a boolean was a nullable varchar(0): null for false, empty string for true. It's a bit of an old one, hopefully this is no longer the case today :)

  • Appalled (unregistered)

    I never use Bools or Integers. I use char(1) strings set to Y or N. And guess what? I can tell at a glance WTF is going on whenever I need to run native queries against any of my databases. Everybody (here at least) loves it and has started to do so themselves.

  • isthisunique (unregistered)

    You should use commonish exceptions and pass the relevant variables back down with the exeption.

    For some people a common exception means one and only one exception. For others it means every possible exception for every possible case.

    Somewhere between that is where you want to be. You often what exceptions for each realm as it is convenient and a minimal level of nesting down the tree of possible exceptions that gives a good hint of where your problem is.

    After that you should largely make them on demand, as in when they are actually needed or likely to be needed.

  • MiserableOldGit (unregistered) in reply to Steve_The_Cynic

    I was thinking "Y" and "N"* but I like your idea better. Could make it an upper case F for one and a lower case f for the other, that should work out just dandy.

    • "Y" == "You must be joking" == 0 "N" == "Now that's right, chuck" == 1
  • foxyshadis (unregistered)

    A char(1) with Y/N is just a int/bool with tests for 89 or 78, it's not like the database is going to use a different datatype or care either way. (For performance and aliasing reasons, a char(1) is often actually uint(4) or uint(8) on the back these days.) At this point, bool vs magic char vs magic integer all comes down to ideological purity, except that bool gives you free sanity checking on insert.

  • John (unregistered)

    More fun would be:

    return checkStarted != 1 ? false : true;

  • Zenith (unregistered) in reply to Friendly_Reminder

    So you've never worked with Indian code? I can't get those assholes to stop storing datetimes in LONG FORM VARCHAR.

  • JD (unregistered)

    Well it's really bad tho but not that bad. Oracle RDBMS doesn't know boolean and when the column is created as NUMBER(X,Y) which is the recommened type the jdbc driver (thin or OCI) will return a BigDecimal.

  • Daniel (unregistered)

    Man this is mild compared to the code I inherited. They were swallowing Exceptions and returning Strings, then calling String.contains() in the caller to "catch" Exceptions.

Leave a comment on “An Exception to the Rule”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article