Je réécris une partie de mon programme.
 
En gros g une classe qui modélise un objet (nannnn ??? sisi, je vous jure)...
 
cet objet a des charactéristiques qui ont des contraites particulières (non null, valeur obligatoirement 2,8,12,16, référence un objet qui doit FORCEMENT exister, etc...)
 
cette classe sera utilisée par une GUI que je programme aussi. G donc un controle total sur le bouzin. Toutefois, la classe pourra etre amenée à etre utilisée hors de mon controle.
 
Ma question : je traite où la vérification des valeurs ?
 
je pensais créer mes propres runtimeException genre NumericExcption, etc...et les documenter pour qu'elles soient catchées qd même.
 
De sorte, je pense que l'api publique spécifierait que la classe risque de lancer des exceptions si on sort des valeurs par ex...
 
C typiquement du runtime à mon avis parce qu'on a aucun moyen de savoir ce que l'utilisateur va rentrer...mais il faut traiter les infos, sinon l'objet est dans un état incohérent. J'ai écarté les while < 0, parce que g aucune moyen de notifier à l'interface qu'il faut réentrer les infos...
 
Je peux aussi tout filtrer dans l'interface, mais ca me semble pas logique.
 
Je voudrais votre avis, ni la javadoc ni le java tutorial ne m'ont aidé sur ce coup...

Si tu fournis une API utilisable par d'autres, alors tu dois thrower les Exceptions qui te semblent pas traitables directement.
Genre t'as une méthode parseDate(String date) bin tu remontes une Exception SaleFormatDeDateException ou un truc du style.
Plus l'utilisateur a de possibilités de rentrer des trucs, plus t'as de chances d'aller au carton. Donc remonte tout bien proprement dans ton infrastructure et affiche les erreurs d'input que t'auras catchées avec une boîte de dialogue dans ta GUI, par exemple.

ok, donc selon toi je fais proprement tt mes runtimeException / utilise les runtimeException existante, et je remonte tout, libre à l'implémenteur de les catcher ou de se torcher avec...
 
ce qui m'ennuie, c que les runtime t pas obligé de les catcher...et je sais pas si mes erreurs sont assez grave pour justifier des exceptions en dur qu'on doit catcher obligatoirement

Ba justement, pourquoi tu passes pas sur Exception plutôt ? T'as une contrainte qui t'oblige à utiliser les RuntimeException ?

non, mais le tuto a une partie sur le dilème du choix des types d'exception...et y'a une phrase qui dit que catcher toutes les runtime c pas intéressant...maintenant c vital pour la cohérence des objets créés (surtout que c destiné à fournir une liste sérialisée utilisée ailleurs, si c pas cohérent on peut se faire chier des jours avant de trouver que ct une couille dans un des objets sérialisés...)
 
je v catcher des exceptions, picétout ...