• CodeWhisperer (cs)

    This is why I counsel my devs not to put their name in the comments...

    -cw

  • Martin (unregistered) in reply to CodeWhisperer

    Check that name against the characters of Office Space.

  • Kodi (cs)

    Effing amazing this has got to be the shortest (and most short sighted) WTF in history!

     

  • TJ (unregistered)

        Naja naja naja .....not gona work here anymore :)

  • damne33 (unregistered)

    wtf is this no-talent ass-clown doing?

  • frosty (cs) in reply to CodeWhisperer
    CodeWhisperer:

    This is why I counsel my devs not to put their name in the comments...

    -cw



    You do?  I'd encourage them to so that I'd know who needs to be shown the light (i.e. given guidance, not the light outside the building).
  • Colin McGuigan (cs) in reply to CodeWhisperer

    Good thing this isn't SQL Server; in SQL Server, unless you explicitly check for the error after every statement and return if you find one, it'll just merrily on its way with the rest of the procedure.  That makes for some even stupider error handling code at times.

  • Pablo Marambio (unregistered) in reply to CodeWhisperer

    Nice way to terminate the application, but I would rather use an infinite loop or something...

  • Jalf (unregistered)
    Alex Papadimoulis:
    <font color="#006600">  --   ------------------------- ---------- -------------------------------------------------   ==
      --   M. Bolton                 2003-06-09 Changed to DIV0 error instead of overflow error     ==
      --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==</font>


    Ah, got to love that comment... Fascinating that someone has actually looked at this, and then thought "Divide by zero would be a much prettier way to handle this"
  • Sean (cs)

    This brings me to something I always wonder about.  What goes through the developer's mind when he or she comes up with this kind of idea?  I can't decide between "This will really wow 'em," or "You know, this is so crazy it just might work!"

  • Dave (unregistered)

    That is akin to how I ski.  The only way I know how to stop is by falling down.

  • ammoQ (cs)

    User defined exceptions? RAISE? Who needs that?
    No really, this is so extremely bad that I asume their usage of this shit is even worst than the implementation. Anyway, I've been creative in the usage of PL/SQL exceptions as well, I wonder when it will make it to the front page...

  • MyName (unregistered) in reply to Jalf
    Anonymous:
    Alex Papadimoulis:
    <FONT color=#006600>  --   ------------------------- ---------- -------------------------------------------------   ==
      --   M. Bolton                 2003-06-09 Changed to DIV0 error instead of overflow error     ==
      --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==</FONT>


    Ah, got to love that comment... Fascinating that someone has actually looked at this, and then thought "Divide by zero would be a much prettier way to handle this"

    What do you expect from the guy? He is a singer, not a developer.

    :)

  • ammoQ (cs) in reply to Pablo Marambio
    Anonymous:

    Nice way to terminate the application, but I would rather use an infinite loop or something...



    Beware. This is PL/SQL. If you do an infinite loop, it _will_ run forever. In some cases, it's even really hard to kill the session without shuting down the database instance. And never, ever try on a production machine what kind of damage an infinite recursion causes.
  • CodeWhisperer (cs) in reply to frosty
    frosty:
    CodeWhisperer:

    This is why I counsel my devs not to put their name in the comments...

    -cw



    You do?  I'd encourage them to so that I'd know who needs to be shown the light (i.e. given guidance, not the light outside the building).

    That's what source control management systems are for.  Keeps track of who made what changes and even gives them a space to explain why they changed what they did.  That way the company has the info, but anyone who stumbles on the code doesn't.  

    Two reasons: 1) after a few years you end up with multi-page change logs at the start of every source file (common); 2) by identifying yourself you're actually opening yourself to legal repercussions if your WTF ever kills someone or loses them millions of dollars (much less common, but it's happened).

    Oh, and third, I recall a fellow I used to work with (who I'll leave nameless to protect the guilty) who wrote a pretty nasty WTF and had his email in the javascript source.  It took about 3 months before he started getting hate mail from clueful users.  

    -cw

  • WeatherGod (cs)

    You know, this preson probably got this "brillant" idea when s/he kept on getting this problem in their own programs.  I am leaning towards "this is crazy enough to work!"


  • Bus Raker (cs)

    This is an example of recovering from errors 'dis' gracefully.

    The real WTF is that they used v_divzero := 7; instead of v_divzero := 5;  Maybe Michael Bolton is a fan of James Bond.

    Well, it definitely was more effective that forcing the overflow error:

    v_divzero := 65535 + 1

    Gotta give him credit for that one!

  • Jojosh_the_Pi (cs)

    The least they could have done is to condense the procedure into 1 line. Unless for some reason,

    v_divzero := 7 / 0;
    throws a different error.

  • Bus Raker (cs)
    Alex Papadimoulis:

    <FONT color=#006600>==
      -- Author:         S. Nagheenanajar                                                           ==
    </FONT>

    Mr. Naghe .... Naghe ..... Naghe .....Naghe .......Naghe

    Mr. Not gonna work here anymore!

    --Office Space

  • Anonymous SQLuser (unregistered) in reply to Colin McGuigan

    I'm pretty sure "SET ARITHABORT ON" fixes that.

    Oh my. That was hard.

  • Anonymous SQLuser (unregistered) in reply to Colin McGuigan
    Colin McGuigan:
    Good thing this isn't SQL Server; in SQL Server, unless you explicitly check for the error after every statement and return if you find one, it'll just merrily on its way with the rest of the procedure.  That makes for some even stupider error handling code at times.

    The ARITHABORT statement above was in reply to this. Can be set in procedures and on DB level.

  • An apprentice (unregistered) in reply to Jojosh_the_Pi
    Jojosh_the_Pi:
    The least they could have done is to condense the procedure into 1 line. Unless for some reason,
    v_divzero := 7 / 0;
    throws a different error.

    You don't get it. The real WTF is that they use magic numbers without wrapping them in constants!

  • TomCo (cs)

    Rich did a good job.  Some manager will need to get the pat on the back though for bringing him in.  What exactly were these developer/employees proficient in?  The following commands should be run on their lil' database:

    <FONT face="Courier New" size=2>sqlpuss scott/tiger</FONT>

    <FONT face="Courier New" size=2>SQL-PUSS>DELETE FROM EMP WHERE JOB = 'PLSQLDEV' AND DEPTNO = (SELECT DISTINCT DEPTNO FROM DEPT WHERE DNAME = 'IT');
    2 row(s) infected.

    SQL-PUSS>COMMIT;

    SQL-PUSS>UPDATE EMP SET SAL = SAL * 2 WHERE JOB = 'MANAGER' AND DEPTNO = (SELECT DISTINCT DEPTNO FROM DEPT WHERE DNAME = 'IT');

    SQL-PUSS>COMMIT;
    1 row(s) infected.

    SQL-PUSS>EXIT</FONT>

    <FONT face="Courier New" size=2></FONT> 

  • marvin_rabbit (cs) in reply to Jalf
    Anonymous:
    Alex Papadimoulis:
    <font color="#006600">  --   ------------------------- ---------- -------------------------------------------------   ==
      --   M. Bolton                 2003-06-09 Changed to DIV0 error instead of overflow error     ==
      --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==</font>


    Ah, got to love that comment... Fascinating that someone has actually looked at this, and then thought "Divide by zero would be a much prettier way to handle this"


    Well, the line that is now:
       v_divzero := v_divzero / 0;
    used to read as:
       v_divzero := v_divzero / 0.00000000000000000000000000000000000001;
    I think we can agree that the new version is much better.
  • Hirudo (unregistered) in reply to Jojosh_the_Pi
    Jojosh_the_Pi:
    The least they could have done is to condense the procedure into 1 line. Unless for some reason,
    v_divzero := 7 / 0;
    throws a different error.


    In most languages the code above would result in a compile time error since constant division is resolved at that stage. To make it a runtime error you really do have to go the long way like he did.
  • LizardFoot (unregistered)

    The intent behind using a divide by zero error here is obvious. 
    Mr. Nagheenanajar and Mr. Bolton knew that divide by zero errors would round the transaction amounts to two decimal points and drop the remaining hundreths of a cent into an joint account accessible only by the product manager, a Mr Peter Gibbons.
    Two consultants, a Mr. Porter and Mr. Slydell were brought in to investigate and found that a shortage of red staplers was the main problem. 


  • Anonymous (unregistered)

    It boggles the mind.

  • JernejL (unregistered)
    <font color="#006600">Changed to DIV0 error instead of overflow error 

    LFMAO this is awesome, a design so wrong gets a new description!

    </font>
  • JoeBloggs (unregistered) in reply to Jojosh_the_Pi
    Jojosh_the_Pi:
    The least they could have done is to condense the procedure into 1 line. Unless for some reason,
    v_divzero := 7 / 0;
    throws a different error.
    That might error out at compile time (for example, if it does constant folding) rather than at runtime.
  • loneprogrammer (cs) in reply to Dave
    Anonymous:
    That is akin to how I ski.  The only way I know how to stop is by falling down.

    Ha!!  <font face="Courier New">throw new BrokenLegException();</font>
  • xrT (cs) in reply to MyName
    Anonymous:
    Anonymous:
    Alex Papadimoulis:
    <FONT color=#006600>  --   ------------------------- ---------- -------------------------------------------------   ==
      --   M. Bolton                 2003-06-09 Changed to DIV0 error instead of overflow error     ==
      --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==</FONT>


    Ah, got to love that comment... Fascinating that someone has actually looked at this, and then thought "Divide by zero would be a much prettier way to handle this"

    What do you expect from the guy? He is a singer, not a developer.

    :)



    lol...i was thinking the same thing..."he's a programmer? wtf?!" :p

    i guess they're thinking that one day datatypes will increase in size and the forced overflow error would not error out anymore...thus using the division by zero error..

  • mrsticks1982 (unregistered)

    Gosh, this brings back oracle nightmares!!!! I know some people who would have done something along this and they would have worked for Assenture!!!

  • marvin_rabbit (cs)

    Transcript of conversion from June 8, 2003.  In attendance are PHB and M. Bolton.

    PHB:  The users say they keep getting "Overflow Errors".  Can you fix that?

    M. Bolton: ...

  • lucky luke (cs) in reply to frosty
    frosty:
    CodeWhisperer:

    This is why I counsel my devs not to put their name in the comments...

    -cw



    You do?  I'd encourage them to so that I'd know who needs to be shown the light (i.e. given guidance, not the light outside the building).


    You do? I just use something like CVS and be able to see exactly what everyone did and not rely on a comment to decide who to blame ;)
  • Paul Tomblin (unregistered)

    At a job I had back in the mid-80s, the same code supported several Unix flavours and VMS.  In order to produce a stack trace on error in VMS, they called the one and only Fortran subroutine in the system to do a divide by zero, since that would force a stack trace.  I had already gotten rid of all the other Fortran remnants on the system, so I attacked the big orange wall and found the documentation on how to produce a stack trace in C with a VMS system call.  I took great pride in removing the last trace of Fortran from that system.

  • dazed (unregistered) in reply to Sean
    Sean:
    This brings me to something I always wonder about.  What goes through the developer's mind when he or she comes up with this kind of idea?  I can't decide between "This will really wow 'em," or "You know, this is so crazy it just might work!"

    Well neither, surely. (But you knew that). It's doubtless the old, old problem of someone who has learnt (or taught himself) to write small single-developer programs and never realised (or been told) that large multi-developer applications require a higher degree of organisation - like proper error handling. "I need to stop the process - this'll stop it." But it sounds as if here most of the original team were the same.

  • Kevan (unregistered) in reply to CodeWhisperer

    That's why I love that the Toroise SVN plug in names the compare with earlier version function "Blame"

  • jackass (cs)

    I find it truly amazing that someone took the time to add comments and a description to a procedure with such a terrible design.

  • anonymous coward (unregistered) in reply to lucky luke
    lucky luke:
    frosty:
    CodeWhisperer:

    This is why I counsel my devs not to put their name in the comments...

    -cw



    You do?  I'd encourage them to so that I'd know who needs to be shown the light (i.e. given guidance, not the light outside the building).


    You do? I just use something like CVS and be able to see exactly what everyone did and not rely on a comment to decide who to blame ;)


    This is why I login to CVS as my boss and don't put comments in - because he cannot complain about his lack of comments

  • Unklegwar (unregistered)

    INSURE is to buy insurance for.

     

    ENSURE is to make sure of.

  • BlackTigerX (unregistered)

    ...at least the name was appropiate

  • Colin McGuigan (cs) in reply to Anonymous SQLuser
    Anonymous:

    I'm pretty sure "SET ARITHABORT ON" fixes that.

    Oh my. That was hard.



    Really?  I'd recommend testing that before saying it.  ARITHABORT does nothing to control-of-flow, so encountering a divide-by-zero still won't cause the running query to terminate.

    Proof:


    SET ARITHABORT ON

    DECLARE @test TABLE (data integer)

    INSERT INTO @test (data) VALUES (1)
    INSERT INTO @test (data) VALUES (1/0)
    INSERT INTO @test (data) VALUES (-1)

    SELECT * FROM @test


    Output (SQL2000, SP4):



    (1 row(s) affected)

    Server: Msg 8134, Level 16, State 1, Line 6
    Divide by zero error encountered.
    The statement has been terminated.

    (1 row(s) affected)

    data
    -----------
    1
    -1

    (2 row(s) affected)

  • enterprise biziclop (unregistered)
  • phithe (unregistered) in reply to Unklegwar

    INSURE is to buy insurance for.

    ENSURE is to make sure of.


    Humor WTF: it was a pun. This was at an insurance company (not an ensurance company)
  • baldvin (cs) in reply to CodeWhisperer

    > This is why I counsel my devs not to put their name in the comments...

    This was also my first thought. I googled for him a little bit, and this address came up: http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendid=20677597

    Now a real WTF: you can't see on that page if that guy is a programmer or not (so you cannot be sure if it is him or not), but in the "Who I'd like to meet" section there is M. Bolton, the same name as in the second comment!!

  • Anonymous SQLuser (unregistered) in reply to Colin McGuigan
    Colin McGuigan:
    Anonymous:

    I'm pretty sure "SET ARITHABORT ON" fixes that.

    Oh my. That was hard.



    Really?  I'd recommend testing that before saying it.  ARITHABORT does nothing to control-of-flow, so encountering a divide-by-zero still won't cause the running query to terminate.

    Proof:


    SET ARITHABORT ON

    DECLARE @test TABLE (data integer)

    INSERT INTO @test (data) VALUES (1)
    INSERT INTO @test (data) VALUES (1/0)
    INSERT INTO @test (data) VALUES (-1)

    SELECT * FROM @test


    Output (SQL2000, SP4):



    (1 row(s) affected)

    Server: Msg 8134, Level 16, State 1, Line 6
    Divide by zero error encountered.
    The statement has been terminated.

    (1 row(s) affected)

    data
    -----------
    1
    -1

    (2 row(s) affected)


    Sorry. My bad. Make that:

    <font face="Courier New">SET ARITHABORT ON
    SET ANSI WARNINGS is OFF
    </font>
    At least it works here in MSSQL 2005.
  • r3jjs (unregistered)

    What makes this so bad is that I do something quite similar in my compiler.  I couldn't find a way to make Javascript just abort so I had to force an error.

    Spend hours reading and googling.

    (Yea, yea, I know, I could have set a global status flag and then tracked it back and after every function call did a 'if (errorLevel == fatal) return;' but that seemed even worse to me.)

    <FONT color=#0000ff>http://motevm.sourceforge.net/</FONT>

    http://motevm.sourceforge.net/motevm/vm.js (killJS at the bottom)

    (Sorry for the lack of documentation, its not been 'released to the wild' yet. Got too busy at work to finish things so its on hold till the end of the season, but if you are curious you can reach me at:
    r3jjs AT yahoo DOT com)

  • PS (unregistered) in reply to enterprise biziclop
    Anonymous:


    As much as I'd like to disagree, you're right. The first thing that came to my mind after reading your post was indeed "WTF?"
  • TomCo (cs) in reply to Unklegwar
    Anonymous:

    INSURE is to buy insurance for.

     

    ENSURE is to make sure of.

    I'm UNSURE about people who are SURE to use ENSURE instead of INSURE.

    "...and don't call me SHIRLEY." ;-P

  • Colin McGuigan (cs) in reply to Anonymous SQLuser
    Anonymous:

    Sorry. My bad. Make that:

    <font face="Courier New">SET ARITHABORT ON
    SET ANSI WARNINGS is OFF
    </font>
    At least it works here in MSSQL 2005.


    Oh, that's true.

    Of course, setting ANSI WARNINGS to OFF means you can't use computed columns or views with indexes.  It also means that varchar data will be truncated without even a warning, so I'm not sure that's the best idea.  And it still won't abort for non-arithmetic errors, such as invalid check constraint or foreign key data. 


Leave a comment on “Insuring Proper Error Handling”

Log In or post as a guest

Replying to comment #:

« Return to Article