macOS Exercise 9-6 Kochan 2.0. Error?

[mdeh]

The exercise reads as follows:

Modify the Calculator class you developed in the exercise from Chapter 4 so that division is done in an @try block. If the division throws an exception, log an error message and continue program execution.

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.

 

[lee1210]

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

 

[mdeh]

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

Lee,
Well, here is something I did not know.

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

 

[lee1210]

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.

#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

 

[mdeh]

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

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

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

 

[skochan]

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?

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.

 

[lee1210]

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.

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

 

[mdeh]

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.

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

 

[skochan]

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

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.

 

[frjonah]

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