There are slight formatting issues in the description of the methods, making especially the description of take hard to read.

add negative is just take positive. I'd do away with either ( one ), and allow negative numbers, before doing away with zeroes.

But I like zero and null cases.

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.

If this is an exercise about APIs, I am not a fan how all incorrect scenarios boil down to identical outcome of IllegalArgumentException (and ValueError). Out of all possible error conditions, the only situations which deserve IllegalArgumentException might be negative amounts, and malformed PINs (i.e. not four digit ones). Situations like incorrect PIN or withdrawal of insufficient funds would deserve a better, more meaningful signal. Such values are legal, they fit domain of the operation, they are just potentially incorrect in given situation. They are user errors, not program errors. They should be, ideally, represented by application-specific exception types.

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!

Your test results expect both the "add" and "take" methods to process a zero amount. In my opinion, a zero amount passed to either of these methods should throw a ValueError.

All of the requirements (including required return values from each function) should be made clear in the description. It should not be necessary to infer these from the test failure messages.

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.

Safe(balance, pin)
Safe(pin)  # same as above, but balance = 0

Safe(pin,balance) would seem to be better design if balance is optional.

If this is only intended to make the kata more difficult, please consider what you're doing there: passing artificially bad design off to your solvers to handle, when completely unnecessary.

Random tests are not optional.

At least some people ( including me ) will downvote your kata, when solved, if it has no random tests. I'd suggest you unpublish your kata now and add random tests, to prevent people from downvoting it simply for not having random tests; they may or may not come back after you've added them to update their vote.

Hello! I am a Codewars bot, and I reviewed your kata for common authoring mistakes.