EDIT: I'm getting a lot of downvotes on this recently. so I thought I'd just add a note that this answer was written before the question underwent it's most recent edit, where returning null was highlighted as an option. which seems very acceptable. Some of my answer was addressed to concerns like that of Edwardo, in the comments, who seemed to be advocating returning a 0. This is the case I was railing against.
ANSWER: I think there's an underlying issue here, which is that division by 0 is not legal. It's an indication that something is fundementally wrong. If you're dividing by zero, you're trying to do something that doesn't make sense mathematically, so no numeric answer you can get will be valid. (Use of null in this case is reasonable, as it is not a value that will be used in later mathematical calculations).
So Edwardo asks in the comments "what if the user puts in a 0?", and he advocates that it should be okay to get a 0 in return. If the user puts zero in the amount, and you
want 0 returned when they do that, then you should put in code at the business rules level to catch that value and return 0. not have some special case where division by 0 = 0.
That's a subtle difference, but it's important. because the next time someone calls your function and expects it to do the right thing, and it does something funky that isn't mathematically correct, but just handles the particular edge case it's got a good chance of biting someone later. You're not really dividing by 0. you're just returning an bad answer to a bad question.
Imagine I'm coding something, and I screw it up. I should be reading in a radiation measurement scaling value, but in a strange edge case I didn't anticipate, I read in 0. I then drop my value into your function. you return me a 0! Hurray, no radiation! Except it's really there and it's just that I was passing in a bad value. but I have no idea. I want division to throw the error because it's the flag that something is wrong.