Validation as a result

Parsing and domain acceptance are two decisions

TryQuantity answers whether text represents a positive integer, not merely whether it can be parsed as an integer. Its first condition delegates numeric parsing to int.TryParse, and its second condition checks that the resulting value is greater than zero. Combining those decisions behind a named helper gives callers a useful domain-level question. The name quantity still needs an explicit policy: this sample accepts positive whole numbers, while another application might permit zero or impose a maximum count.

Read the Boolean before the out value

The text 3 parses successfully and satisfies the positive check, so the first if body prints three. The second call parses negative one successfully but rejects it as a quantity, and WriteLine prints False. That second call uses a discard because the caller only wants the acceptance result. Notice that the false result does not necessarily mean numeric parsing failed. It can also mean parsing succeeded and the later domain condition failed, which is precisely what happens in this sample.

bool TryQuantity(string text, out int value) => int.TryParse(text, out value) && value > 0;

Short-circuiting preserves a clear evaluation order

The && operator evaluates the positive-value condition only if TryParse returned true. A parsing failure therefore cannot accidentally be accepted because of an unrelated later condition. The out parameter is assigned by the parsing call, but callers must still respect the helper’s Boolean contract before treating it as a valid quantity. In particular, when negative one parses and then fails the positivity test, the out value can remain negative one. Returning false does not universally reset every try-style helper’s output to zero.

One false result may hide several useful error categories

A compact Boolean helper is appropriate when callers need only accepted or rejected. A detailed import interface may need to distinguish malformed text, numeric overflow, zero, negative values, and a count above an application maximum. Do not make users reverse-engineer those cases from a single generic message if they require different corrections. Conversely, avoid throwing exceptions for every ordinary invalid entry solely to recover distinctions that a richer validation result could represent directly and predictably.

Practice: build a quantity acceptance table

Test text for an empty input, a word, zero, negative one, one, and a very large integer outside int range. Record the acceptance result separately from any out value you inspect for learning. Then change the policy to allow zero and identify exactly which test expectation changes. These variations isolate numeric representation from domain rules and prevent a successful parser call from being mistaken for proof that the requested business operation is meaningful.

• Only use the parsed value as an accepted quantity when the helper returned true.
• Treat a compiler diagnostic or a thrown programming error separately from an ordinary false validation result.

Practice: return an explanation without inventing a quantity

For an independent redesign, return a small result containing success, a possible quantity, and a named reason when validation fails. Keep parsing failure distinct from nonpositive input, and add a maximum of one hundred. Try the boundary values ninety-nine, one hundred, and one hundred one. Make the result impossible to misread as a valid zero quantity when failure occurred. You do not need a large framework; a small explicit model and a table of expected outcomes are enough to clarify the contract.

• Define whether whitespace and a leading sign belong to the accepted text format rather than inheriting an accidental policy.
• For machine-exchanged numeric text, choose explicit NumberStyles and invariant culture when that is the required format.

Keep the small helper honest about its promise

The baseline is intentionally narrow and works with ordinary managed parsing available in the browser runtime. It demonstrates how a Boolean result can combine a representation check with one domain restriction. When adapting it, state the text format, numeric range, allowed quantity range, and meaning of failure. SharpRune’s invariant browser configuration makes culture-dependent demonstrations inappropriate unless their behavior is explicitly supported; a portable machine format should be specified, while human-facing input may require a different boundary in a full application.

• Expected baseline: 3, then False on the next line.
• Negative one is valid integer text but not a valid quantity under this helper’s rule.
• The Boolean result is authoritative; the out value alone is not evidence of acceptance.