<aside> 🧩

Prerequisiti

• Aver completato le Parti 1, 2 e 3 (Weapon, Player, Potion, @property).
• Aver studiato la gestione delle eccezioni. </aside>

<aside> 🧠

Cosa imparerai con questo esercizio

• Come e perché validare i dati di input usando raise.
• Rendere le classi “auto-difensive” sollevando eccezioni per stati non validi (es. ValueError, TypeError).
• Come gestire gli errori nel ciclo di gioco principale usando try…except.
• Utilizzare la clausola else per la logica che deve seguire un try riuscito.
• Applicare i principi di Clean Code per separare la logica di gioco dalla gestione degli errori. </aside>

<aside> 📢

Novità

• Validazione attiva (fail-fast): le classi non accetteranno più “silenziosamente” dati errati, ma falliranno immediatamente sollevando un’eccezione.
• Gestione degli errori: il ciclo di gioco principale (nel main) diventerà il “gestore” degli errori, decidendo cosa fare quando un’azione (attacco, uso pozione) fallisce. </aside>

Obiettivo

L’obiettivo di questa “Parte 4” non è aggiungere nuove classi, ma rendere robusto il codice esistente. Attualmente, molti metodi (come take_damage o i costruttori) accettano valori non validi (es. take_damage(-10)) e per evitare la “corruzione” dello stato del gioco forzano dei valori di default. Questo, ovviamente, non è il modo corretto di trattare e gestire gli errori: si evita di mandare in crash il programma, ma il gioco comunque non funzionerà come ci si aspetta.

In generale, se qualcosa è andato storto e l’esecuzione del programma non può proseguire, la linea d’azione corretta è quella di gestire l’eccezione e terminare “ordinatamente” il programma.

In questo esercizio, modificherai le classi Weapon, Player e Potion affinché sollevino eccezioni quando ricevono dati o si trovano in stati non validi. Successivamente, modificherai il main.py per catturare queste eccezioni e impedire che il programma vada in crash, informando l’utente dell’azione fallita.

Specifiche delle classi (refactor)

Dovrai modificare le classi esistenti per introdurre la validazione.

1. Classe Weapon

• __init__(self, …):
  • Implementa la validazione. Solleva ValueError con messaggi chiari se:
    • name è una stringa vuota.
    • min_damage è minore di 1.
    • max_damage è minore di min_damage.
    • type non è né “melee” né “ranged”.

2. Classe Player

• __init__(self, …):
  • Aggiungi la validazione per i parametri numerici. Solleva ValueError se max_hp, strength o dexterity sono minori o uguali a 0.
• take_damage(self, amount: int):
  • Questo metodo è fondamentale. Aggiungi due controlli:
    • Solleva TypeError se amount non è un numero intero (int).
    • Solleva ValueError se amount è un numero negativo (es. < 0). Non si può “subire” danno negativo.
• heal(self, amount: int): (se hai creato questo metodo nella Parte 3)
  • Simile a take_damage, solleva TypeError se amount non è int e ValueError se amount < 0.
• equip(self, weapon):
  • Verifica che l’oggetto weapon sia valido (usando il duck typing della Parte 3). Se l’oggetto non ha il metodo get_damage O non ha il metodo get_type (o come lo hai chiamato), solleva un TypeError con un messaggio tipo: “Oggetto non equipaggiabile, non è un’arma valida.”

3. Classe Potion