Nullable int c#

uint?
Integral numeric types (C# reference)

Esetleg a coalescing operátorral:

A fenti csak egy példa, az ellenőrzés már a feladattól függ. A feltételt úgy tedd össze, hogy a vizsgálat első tagja a null vizsgálat legyen, aztán jöhet a többi, mondjuk a 0-a, majd az, hogy ne legyen kisebb, mint 0-a.
A 0-a vizsgálat így is lehet:

uint? vagy property és negatív értékadás esetén lekezelni (konverzió, hibastátus vagy exception)

Esetleg Property-vel?

Bocs a formázásért. Amikor kimásoltam a VS-ből még megvoltak a TAB-ok...

bár minden nagyban függ a contexttől én nem szoktatnám rá a kérdezőt, hogy kivételt dobjon egy property setterében. (getterben meg pláne). Mert még a végén a public prop-ba is ugyanezt csinálja.

property írásakor csak egy értéket adok.
someProp = 12;
a legutolsó ahol kivételt várok, az egy értékadás
ez egyből elvárja, hogy én pontosan tudjam annak propertynek a belső működését.
Holott én csak annyit akarok tudni, hogy nem lehet nullánál kissebb

ez hatványozottan nagy probléma, ha UI-ra is ki van bibndolva (rácsodálkozhat az ember, hogy egy exception valahol elveszett a semmiben)

Hogy serializációnál mit okoz, azt nem tudom, de valszeg az se örül neki.

és biztos van még vagy ezer ok, hogy miért ne


lehet egyszerűbb lenne, ha csak olvasható prop lenne, és az írást függvényen keresztűl oldaná meg. ott meg már nyugodtan mehet az ellenőrzés meg a kivétel

Esetleg ez:

How to force a number to be in a range in C#?

Lehet, hogy nem kellene rászoktatni, de a problémájára megoldást jelenthet. A Setter részben validáljuk, hogy érvényes-e a megadott érték.

Hasonló kérdés és hasonló válasz erre a problémára itt, annyi különbséggel, hogy a sima Exception helyett ArgumentOutOfRangeException van:

Is there any way in C# that I can limit the range of an int variable?

Pedig szerintem hasznos lenne, ha tudnám, hogy oda azt az értéket nem tudom betuszkolni.

Most megnéztem a következő kódot és nincs kivétel, viszont a memóriában echte rossz érték lesz. Mivel nem kaptam exception-t így ezzel számolok adott esetben tovább ami szerintem hiba:

W.

A túlcsordulás ellenőrzése relatíve drága dolog, ezért nincs alapesetben bekapcsolva. De ha ez neked valahol fontos, akkor a checked kulcsszó a barátod.

Most már engem is érdekelne a megoldás, egy konkrét példán keresztül.

szerintem erre nehéz igy látatlanban konkrét példát mondani.

Ha a csapat megegyezik abban, hogy egy property setter dobhat kivételt (és ez a kód-ban szerepel is jól láthatóan (/// <exception cref="ArgumentOutOfRangeException">if lower than 0</exception>)
akkor miért ne mehetne.
Ebben az esetben a UI-t is úgy készítem fel, hogy validateexception.
Meg mindenki másnak is figyelnie kell. Jól kell dokumentálni,

és mindenkinek uptodate kell lennie.
Azért valjuk be, az ember ritkán tesz trycatch-be egy értékadást.

ha ez sehova sincs leírva, akkor a vizsgálat az értékadás elött történhetne, amennyiben ez a közös megállapodás (azaz a hívónak tudnia kell, hogy az adott prop nem lehet kissebb mint 0)
A setter-be mehetne egy debug.assert
és a kivételt ott dobnám, ahol ezt az értéket fel akarom használni. bár ez már utólag meg nem mondja, hogy hol lett negatív éles környezetben

esetleg egy setter függvényben oldanám meg, amiben nyugodt szívvel dobok kivételt.

de ehhez le kell ülni és megnézni, hogy mi a környezet.
ha nincs UI, nem akar egy másik dll reflectionnal beleírkálni, stb, stb, stb akkor semmi gond az exceptionnal.