Jump to content

  • Log In with Google      Sign In   
  • Create Account


Dividing by zero, on purpose


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
16 replies to this topic

#1 JD_Rushing   Members   -  Reputation: 221

Like
0Likes
Like

Posted 31 October 2013 - 09:53 PM

Just curious if anyone else does this.

Sometimes I have an if statement block I don't know is running.  I know the code before, and after, the block is running fine.

So, I put a divide by zero after it.  I know there are more sophisticated ways of debugging, and I have used them.  But for a quick and dirty, I make an error by dividing by zero.  I was going to stop the program anyways.

 

So I was just curious if anyone has ever purposely made an error in a section of code to see if part of it was running or not?

 



Sponsor:

#2 Khaiy   Crossbones+   -  Reputation: 1342

Like
10Likes
Like

Posted 31 October 2013 - 09:59 PM

I usually just put in a breakpoint and watch to see if it's hit or not. If I have something more complex, I debug in the console and have each block print a message each time it's executed, which lets me home in on what I'm looking for pretty quickly. The latter is also nice for hunting down more specific issues inside of a block, rather than just seeing if it's executing or not.

 

I've never thrown in a line meant to give my compiler a conniption, but I guess that would work as well as anything else.



#3 Dragonsoulj   Crossbones+   -  Reputation: 2015

Like
1Likes
Like

Posted 31 October 2013 - 10:30 PM

I'm with Khaiy. Depending on the language, I either go with breakpoints, alerts/message boxes, or debug printing (usually to the console, but, for instance, PHP and webpages, I just print to the page).



#4 SiCrane   Moderators   -  Reputation: 9489

Like
4Likes
Like

Posted 31 October 2013 - 11:00 PM

The only time I've ever deliberately put a divide by zero into my code was to check if my exception handler was actually catching divide by zero and other non-C++ exceptions. 



#5 Postie   Members   -  Reputation: 882

Like
5Likes
Like

Posted 31 October 2013 - 11:25 PM

If I'm about to head home for the day and I'm working on a piece of code that is incomplete but compilable, I'll type some garbage like: "dgsahjgda". That way when I come back to it in the morning If I forget where I was up to, it'll take me straight to the garbage when I try to compile. 

 

I'll do the same if I'm doing some manual refactoring involving a lot of copy and pasting.


Currently working on an open world survival RPG - For info check out my Development blog: ByteWrangler

#6 tonemgub   Members   -  Reputation: 717

Like
4Likes
Like

Posted 01 November 2013 - 01:24 AM

If I'm about to head home for the day and I'm working on a piece of code that is incomplete but compilable, I'll type some garbage like: "dgsahjgda". That way when I come back to it in the morning If I forget where I was up to, it'll take me straight to the garbage when I try to compile. 

 

I'll do the same if I'm doing some manual refactoring involving a lot of copy and pasting.

I do this too, but instead of garbage, I write down the possible reason for why the code might be failing, or whatever thought I happened to have about it.



#7 N.I.B.   Members   -  Reputation: 1067

Like
3Likes
Like

Posted 01 November 2013 - 01:36 AM

I work mostly in C++, so I usually use __debugbreak() (or __asm int 3).



#8 Paradigm Shifter   Crossbones+   -  Reputation: 5203

Like
4Likes
Like

Posted 01 November 2013 - 02:12 AM

 

If I'm about to head home for the day and I'm working on a piece of code that is incomplete but compilable, I'll type some garbage like: "dgsahjgda". That way when I come back to it in the morning If I forget where I was up to, it'll take me straight to the garbage when I try to compile. 

 

I'll do the same if I'm doing some manual refactoring involving a lot of copy and pasting.

I do this too, but instead of garbage, I write down the possible reason for why the code might be failing, or whatever thought I happened to have about it.

 

 

#error

 

is probably what you are looking for.

 

Breakpoints is what the OP is looking for?


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#9 N.I.B.   Members   -  Reputation: 1067

Like
0Likes
Like

Posted 01 November 2013 - 02:16 AM


Breakpoints is what the OP is looking for?

Yep.



#10 Paradigm Shifter   Crossbones+   -  Reputation: 5203

Like
5Likes
Like

Posted 01 November 2013 - 02:28 AM

#error is also good as a sanity check (is this bit of code even being compiled?!), which can occur if you have lots of conditional compilation going on (or inside a header file if you aren't sure whether it is being included).

 

EDIT: Dividing by zero isn't very reliable anyway, if you don't store the result it can be optimised out and floating point division by zero results in one of +/-infinity or NaN. If the compiler can detect an unconditional divide by zero it might give a compile time error too. So I second __debugbreak() or whatever does the same thing in your compiler.

 

EDIT2: Assuming C/C++ anyway


Edited by Paradigm Shifter, 01 November 2013 - 02:36 AM.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#11 Ohforf sake   Members   -  Reputation: 1658

Like
1Likes
Like

Posted 01 November 2013 - 02:49 AM

I once had to track down a bug on a console testkit (you can only debug on the devkits, not on the testkits).
However, even with the testkit, you got a full crash dump with all the variables when memory access violations like *((unsigned*)0) = 0; were accidentally to occure.

#12 Orangeatang   Members   -  Reputation: 1430

Like
7Likes
Like

Posted 01 November 2013 - 03:06 AM

Heh heh, the only thing I've intentionally used a divide by zero for is a big red "Don't press this" button :)

 

Setting a break point (as suggested earlier) is probably your best bet, but you could also use an: 

assert( false );

to stop your program from executing.



#13 Paradigm Shifter   Crossbones+   -  Reputation: 5203

Like
0Likes
Like

Posted 01 November 2013 - 03:09 AM

assert is likely to only work in debug builds though.


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#14 King of Men   Members   -  Reputation: 391

Like
0Likes
Like

Posted 01 November 2013 - 10:09 AM

If you're at the point of testing whether some code is even running, you should really be doing debug builds. 


To win one hundred victories in one hundred battles is not the acme of skill. To subdue the enemy without fighting is the acme of skill.

#15 Khatharr   Crossbones+   -  Reputation: 2908

Like
1Likes
Like

Posted 01 November 2013 - 01:36 PM

assert is likely to only work in debug builds though.

 

I don't think division by zero is a release-minded feature. YMMV biggrin.png

 

If you're one of them as sets your debug builds to be super-similar to your release builds, then you're already digging in the options, so you can just leave asserts enabled. honestly, though, a breakpoint is the better option.


void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#16 Paradigm Shifter   Crossbones+   -  Reputation: 5203

Like
1Likes
Like

Posted 01 November 2013 - 02:11 PM

If you don't know whether some code is actually running I'll wager it's probably because of a difference between the debug and release builds anyway (most likely an uninitialised variable). At least with a breakpoint the debugger probably activates. Putting a divide by zero in may just crash a release build which doesn't help much unless you get a different type of crash.

 

Back in the PS1 days we used to do an assert as while(1) pollhost(); which just hangs but forced the debugger to be responsive (since pollhost transferred the execution state data to the PC and enabled interrupts; if you just hang the machine you couldn't see what was being executed it would debug break in the routine which called pollhost which was usually either the vertical blank interrupt service routine or the main game loop). That scenario is quite common for remote debugging.


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#17 Ezbez   Crossbones+   -  Reputation: 1164

Like
1Likes
Like

Posted 02 November 2013 - 08:49 AM

The very first game I wrote I didn't know how to handle events well enough to get it to quit in a natural way. So I had the escape key just divide by zero so that it would exit.

 

My proudest moment.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS