Exercise 9-6 Kochan 2.0. Error?

Discussion in 'Mac Programming' started by mdeh, Jan 20, 2009.

  1. macrumors 6502

    Joined:
    Jan 3, 2009
    #1
    The exercise reads as follows:


    I cannot get my computer to throw an exception with either integer or float when dividing by 0. Is it possible that when the exercise was written, the pre-intel machines acted differently? NO laughing please! Perhaps I have misunderstood the intention of the question, but I thought it was to replace the if/else statements when checking for zero.
     
  2. macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #2
    Having no idea what the excercise is, from previous posts I believe you have a fraction class, complex class, etc. You can't rely on the processor to throw an exception (you should get an interupt), you need to check the denominator and throw the exception. I could be wrong, but this is what makes most sense to me.

    Also, Obj-C 2.0 was made available with 10.5, so intel was definitely in the picture.

    -Lee
     
  3. thread starter macrumors 6502

    Joined:
    Jan 3, 2009
    #3
    Lee,
    Well, here is something I did not know.

    Code:
    #import <Foundation/Foundation.h>
    
    int main (int argc, const char * argv[]) {
        NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    	int n = 0;
    	float f = 0.00;
        NSLog(@"%f", 1/f);  /* inf  */
    	
    	NSLog(@"%d", 1/n); /*exception */
        [pool drain];
        return 0;
    }

    So, I guess If you go back to the **original** calculator class ( which I think used an int for the accumulator) the exercise should work.
     
  4. macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #4
    I am possibly/probably speaking from a position of ignorance, since i don't have 2.0 available, but on my machine 1 / 0 yields an EXC_ARITHMETIC signal, killing the program. It's certainly possible that the 2.0 runtime sets up a signal handler somehow to turn this into an exception, but i just can't say.

    Code:
    #import <Foundation/Foundation.h>
    
    int main(int argc, char *argv[]) {
      NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
      @try {
        int x = (int)((int)1 / (int)0);
      }
      @catch (id theException)
      {
        NSLog(@"Caught exception!");
      }
      [pool release];
      return 0;
    }
    This may behave differently under 2.0, but on my machine "Caught exception!" is not printed, the program dies at the division by 0. I over-cast to int just to be sure.

    -Lee
     
  5. thread starter macrumors 6502

    Joined:
    Jan 3, 2009
    #5

    No, I get about the same on my MacPro with this.


    Code:
    #import <Foundation/Foundation.h>
    int main(int argc, char *argv[]) {
    	NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    	@try {
    		NSLog(@"%i", 7/0);
    	}
    	@catch (NSException *exception) {
    		NSLog(@"%@%@", [exception name], [exception reason]);
    	}
    	
    	[pool release];
    	return 0;
    }
    Error: The Debugger has exited due to signal 8 (SIGFPE).The Debugger has exited due to signal 8 (SIGFPE). From a contributor on the Obj-C list (OC):"The zero-division does not raise an exception, instead it "signals the process", which at the level we are can be roughly translated to "the process just crashes".
    All exceptions are raised programmatically -- at some code level there must be a @throw. "Signals" though are generated by the CPU itself."

    Steve....any ideas?
     
  6. macrumors regular

    Joined:
    Apr 1, 2006
    Location:
    California
    #6
    Yes, that's accurate. The division by zero is caught by the hardware and won't generate an exception as I had originally surmised.

    I can't think of a suitable exercise to replace this one that involves exception handling and is also practical up to this point in the text. :confused:
     
  7. macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #7
    Steve,

    Since you've had (I think... don't have the text, sorry =) ) the reader build a fraction class, etc. if there is a divideByFraction: method or something similar, could you have them check that the numerator of the divisor is 0, and throw an exception at that point? Then you would put a @try/@catch around the call to divideByFraction: to catch this exception if thrown?

    While a little less intuitive, you could also have an exception generated by an init method on fraction if the denominator is 0.

    -Lee
     
  8. thread starter macrumors 6502

    Joined:
    Jan 3, 2009
    #8

    Steve...when you wrote the exercise for the original vs 1 of the book, was the exercise valid then? I am curious as to what has changed to give a better understanding of the underlying issue you are trying to demonstrate.
    thanks
     
  9. macrumors regular

    Joined:
    Apr 1, 2006
    Location:
    California
    #9
    Lee,

    Thanks! Those are both excellent suggestions, and I really like the first one a lot. The problem I have is that I haven't shown how to instantiate an NSException object and fill it with information before throwing the exception. I'll see if I can somehow squeeze that explanation into the next printing (there might be enough room at the end of the chapter).

    Thanks again for the suggestions.

    Cheers,

    Steve K.
     
  10. macrumors regular

    Joined:
    Feb 2, 2009
    Location:
    Almost Heaven... WV
    #10
    Thanks for posting...

    To all,

    Thanks for posting. That excercise was driving me nuts!

    Stephen,

    It's great to know you're on here and reviewing posts... The text is great...I have already recommended it to several friends.

    Best Regards,

    jonah
     

Share This Page