That's a really thoughtful point, and you're absolutely right in terms of good API design — user errors (wrong pin, insufficient funds) and programmer errors (malformed input, negative amounts) are conceptually different, and in a real-world API they'd deserve distinct, purpose-built exception types.

For this kata specifically, I kept everything under a single exception type on purpose, mainly to keep the difficulty appropriate for a 7 kyu level and make it approachable to as many solvers as possible — introducing custom exception hierarchies felt like it would shift the focus away from the core exercise (constructors, validation, basic class design) and add complexity that isn't really the point here.

It's a fair trade-off to question though, and I appreciate you laying out the reasoning so clearly — it's given me something to think about for future katas where the domain modeling itself might be more central to the exercise.

Thanks for the input! This was actually an intentional design choice on my part — passing 0 to add or take is a no-op (nothing gets added, nothing gets withdrawn), so I didn't see a strong reason to forbid it. It also let me reuse the same validation logic for the constructor's balance and for amounts in add/take, since balance = 0 is explicitly allowed.

That said, if you feel this is important enough to change, I'm happy to update the test cases to raise a ValueError on zero as well — just let me know!

Thanks for pointing this out - that's a fair catch. You're right, the description should be self-contained and I shouldn't rely on solvers figuring out return types (or the lack thereof) from test failures.

I've updated the description to explicitly state:

• check returns an int (the balance)
• add doesn't return anything
• take returns an int (the withdrawn amount)

This applies to both the Java and Python versions now. Appreciate you flagging it - let me know if anything else is still unclear!

Thank you for taking the time to leave this feedback — I really appreciate it! I'm still fairly new to creating katas, so comments like this are genuinely helpful for me to improve.

Regarding the constructor argument order: you're right, and I've fixed it. The Python version now uses Safe(pin, balance=0) instead of the original Safe(balance, pin).

I'll admit I haven't fully figured out how translations/descriptions work across languages yet, but I did my best to update the description to reflect the fix. Let me know if anything still looks off!

Also added random tests as you suggested — thanks again for pointing that out, I wasn't aware that was expected as a standard practice here.