Comment On Insuring Proper Error Handling

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

-cw

Check that name against the characters of Office Space.

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

 

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

wtf is this no-talent ass-clown doing?

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).

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.

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

Alex Papadimoulis:

  --   ------------------------- ---------- -------------------------------------------------   ==

  --   M. Bolton                 2003-06-09 Changed to DIV0 error instead of overflow error     ==

  --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==

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"

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!"

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

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...

Anonymous:

Alex Papadimoulis:

  --   ------------------------- ---------- -------------------------------------------------   ==

  --   M. Bolton                 2003-06-09 Changed to DIV0 error instead of overflow error     ==

  --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==

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.

:)

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.

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

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!"

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!

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.

Alex Papadimoulis:

==
  -- Author:         S. Nagheenanajar                                                           ==

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

Mr. Not gonna work here anymore!

--Office Space

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

Oh my. That was hard.

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.

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!

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:

sqlpuss scott/tiger

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

 

Anonymous:

Alex Papadimoulis:

  --   ------------------------- ---------- -------------------------------------------------   ==

  --   M. Bolton                 2003-06-09 Changed to DIV0 error instead of overflow error     ==

  --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==

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.

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.

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. 

It boggles the mind.

Changed to DIV0 error instead of overflow error 
 
LFMAO this is awesome, a design so wrong gets a new description! 
 

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.

Anonymous:

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

Ha!!  throw new BrokenLegException();

Anonymous:

Anonymous:

Alex Papadimoulis:

  --   ------------------------- ---------- -------------------------------------------------   ==

  --   M. Bolton                 2003-06-09 Changed to DIV0 error instead of overflow error     ==

  --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==

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..

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

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: ...

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 ;)

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.

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.

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

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

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

INSURE is to buy insurance for.

 

ENSURE is to make sure of.

...at least the name was appropiate

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)

The real WTF is:

Seven deadly sins

Seven ways to win

Seven holy paths to hell

And your trip begins



Seven downward slopes

Seven bloodied hopes

Seven are your burning fires,

Seven your desires...

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)

> 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!!

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:

SET ARITHABORT ON
SET ANSI WARNINGS is OFF

At least it works here in MSSQL 2005.

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.)

http://motevm.sourceforge.net/

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)

Anonymous:

The real WTF is:

Seven deadly sins

Seven ways to win

Seven holy paths to hell

And your trip begins



Seven downward slopes

Seven bloodied hopes

Seven are your burning fires,

Seven your desires...

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?"

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

Anonymous:

Sorry. My bad. Make that:

SET ARITHABORT ON
SET ANSI WARNINGS is OFF

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.