Coding interviews
using System;
using System.Linq;
using System.Collections.Generic;
using System.Globalization;
using System.Text;
Console.WriteLine("total:"+Bill(3,125));
Console.WriteLine("large:"+Bill(2,int.MaxValue));
bool rejected=false; try { Bill(2,long.MaxValue); } catch(OverflowException) { rejected=true; }
Console.WriteLine("overflow rejected:"+rejected.ToString().ToLowerInvariant());
static long Bill(int quantity,long unitCents) { if(quantity<0 || unitCents<0) throw new ArgumentOutOfRangeException(); return checked(quantity*unitCents); }
Reveal answer and reasoning
The output lines, in order, are “total:375”; “large:4294967294”; “overflow rejected:true”. Three units at one hundred twenty-five cents produce three hundred seventy-five. Two units at int.MaxValue cents produce 4294967294 because the long price operand makes multiplication occur in the wider type. Two units at long.MaxValue overflow that type, and the harness records explicit rejection rather than printing a wrapped negative amount.
The wide-product fixture is intentionally larger than int.MaxValue but still valid as long. It catches code that multiplies two ints first and casts afterward. The overflow fixture then exceeds long itself, demonstrating that widening and checked arithmetic solve different parts of the numeric contract.
The arithmetic and validation are O(1) time and auxiliary storage for fixed-width inputs. Widening only after an int multiplication would be too late to repair overflow. Checked syntax must cover the actual multiplication inside the method; a checked caller context does not retroactively change unchecked arithmetic in another method. Using decimal does not remove the need for domain units, bounds or overflow handling.
Swallowing overflow and returning zero can turn invalid input into an apparently free order. An exception also needs a consistent API boundary so callers can distinguish invalid quantity from an unrepresentable accepted calculation.
What a strong answer covers
- Exact output: total:375 | large:4294967294 | overflow rejected:true
- Three units at one hundred twenty-five cents produce three hundred seventy-five.
- Using decimal does not remove the need for domain units, bounds or overflow handling.
Common pitfall
Using decimal does not remove the need for domain units, bounds or overflow handling. Swallowing overflow and returning zero can turn invalid input into an apparently free order. An exception also needs a consistent API boundary so callers can distinguish invalid quantity from an unrepresentable accepted calculation.
Follow-up questions
- Test zero quantity, zero price, a negative operand and the largest representable successful product. Hint: derive the safe boundary by division before multiplication, while retaining checked arithmetic as the final guard.
- Where should rounding occur if prices arrive in fractional cents before aggregation?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.