[CICLO 2] Storia 2

[fek]

PlayArea.java R.I.P.
Una vita breve ma intensa.

A presto i test della Storia 2, quando Vicius e' contento del refactoring e della copertura dei test. C'e' da testare la classe Bounds (ex Extents).

[71104]

ehm, scusate ma io stavo facendo il task 5.9 assegnatomi...
almeno avvisare per evitare di farmi lavorare inutilmente...
ora che devo fare?

[fek]

Originariamente inviato da 71104

ehm, scusate ma io stavo facendo il task 5.9 assegnatomi...
almeno avvisare per evitare di farmi lavorare inutilmente...
ora che devo fare?

Non hai lavorato inutilmente, hai fatto uno spike. Ma nella code base non ci dev'essere codice non testato per alcun motivo.

Aspettiamo i test e poi possiamo passare all'implementazione.
Nel frattempo e' un'ottima occasione per cercare opportunita' di refactoring nel codice e per aggiungere qualche test in zone deboli.

[^TiGeRShArK^]

Originariamente inviato da fek

Se la colpa e' di qualcuno, e' mia. Non voglio piu' vedere post di questo tipo.

Ti kiami Chet di secondo nome???



cmq io avrei voluto scrivere qualke test..
nei miei task ho solo dovuto modificare del codice già esistente ed ELIMINARE dei test ke testavano assunzioni non più vere.....

[VICIUS]

Dunque sto navigando il codice con clover e ho trovato un bel po di metodi non testati. Questa sera dovrei riuscire a scrivere quelli che mancano.

Come ultima cosa avrei una proposta da fare. Perchè non eliminare tutte queste eccezioni ? Possibile che ogni votla che si accede ad una proprieta, si carica un suono o una texture ci sia da fare una try/catch ? Tutto quello che facciamo ora è intercettare l'eccezione e terminare il programma. A questo punto ci conviene terminare il programma invece di generare l'eccezione.

In locale le ho rimosse tutte e il codice ne guadagna in quanto a leggibilità. e di molto.

ciao

[71104]

veramente io le eccezioni le trovo comodissime perché imho non ti devi neanche preoccupare di catturarle: se qualcosa va storto e non la catturi il programma si ferma e puoi vedere di preciso dov'è stata lanciata l'eccezione
molto più comodo che tutti quei valori di ritorno, anche perché Eclipse ti mette automaticamente il throws nei metodi

[VICIUS]

Originariamente inviato da 71104

veramente io le eccezioni le trovo comodissime perché imho non ti devi neanche preoccupare di catturarle: se qualcosa va storto e non la catturi il programma si ferma e puoi vedere di preciso dov'è stata lanciata l'eccezione
molto più comodo che tutti quei valori di ritorno, anche perché Eclipse ti mette automaticamente il throws nei metodi

Certo sono utili ma usarle per tutto mi sembra stupido. Se c'è una eccezione va gestita in modo sensato non con un catch vuoto o un throws come stiamo facendo noi ora.
Se guardi per ora dentro ai catch ci sono solo queste cose:

Utils.fatalError(..);
assertTrue(false);
fail(...);

A questo punto Eliminiamo le eccezioni e spostiamo il fatalError dentro alle classi che generano le eccezioni.

ciao

[fek]

Originariamente inviato da VICIUS

In locale le ho rimosse tutte e il codice ne guadagna in quanto a leggibilità. e di molto.

ciao

Io direi di lasciare le sole eccezioni che segnalano un comportamento "eccezionale" (file non trovato, ad esempio) e non un semplice errore di programmazione.

E far fuori tutto il resto.

[cisc]

ma guarda che in java ci sono le eccezioni fatte proprio per segnalare gli errori di programmazione (eccezioni unchecked), ereditano da RuntimeException e non devono essere catturate per forza (tipo IllegalArgumentException è un'eccezione unchecked), quindi quando c'è da segnalare valori anomali di paramentri (quindi dovuti ad errori di programmazione) sono utlissime e non aggiungono nessun fastidio eccessivo, al contrario, quando manca la texture da caricare, per esempio, mi sembrano abbastanza utili ed eleganti...

[VICIUS]

Originariamente inviato da fek

Io direi di lasciare le sole eccezioni che segnalano un comportamento "eccezionale" (file non trovato, ad esempio) e non un semplice errore di programmazione.

E far fuori tutto il resto.

uhm non sono d'accordo. preferisco usare fatalError per stampare un messaggio significativo come "errore: non riesco a caricare la texture `data/diamond.png' quindi esco" che lanciare una eccezione per poi ritrovarmi un inutile e.printStackTrace(); system.exit(-1); o peggio ancora un throws che lascia arrivare il tutto alla jvm.

ciao

[VICIUS]

Originariamente inviato da cisc

ma guarda che in java ci sono le eccezioni fatte proprio per segnalare gli errori di programmazione (eccezioni unchecked), ereditano da Ru[...]

Uhm interessante questa storia delle unchecke exception. Spiega un po'

ciao

[cisc]

per quanto riguarda il discorso di eliminare le eccezioni e mettere delle semplici chiamate a Util.fatalError non sono d'accordo, già il fatto che nel corpo del programma catturi l'eccezione e lanci fatalError mentre nei test lanci fail per esempio è un motivo per mantenere le cose come stanno, inoltre lasciano la libertà di gestire diversamente gli errori in diversi posti del programma...

per le eccezioni unchecked, questo è un pezzo di codice preso dal costruttore di Bounds:

        if(!rectIsInsideTheScreen(left, top, width, height, config))

        {

            throw new IllegalArgumentException();

        }

l'eccezione lanciata è un'eccezione unchecked, infatti non c'è nessun throws nell'intestazione del metodo, e quando costruisci Bounds non devi necessariamente usare un try..catch, anche se volendo si può anche aggiungere, in genere questo tipo di eccezioni vengono usate per segnalare errori di programmazione, ovvero casi che normalmente non dovrebbero verificarsi ma che è bene segnalare correttamente nel caso si verifichino anche per non avere sorprese in seguito...

[fek]

Originariamente inviato da cisc

per quanto riguarda il discorso di eliminare le eccezioni e mettere delle semplici chiamate a Util.fatalError non sono d'accordo, già il fatto che nel corpo del programma catturi l'eccezione e lanci fatalError mentre nei test lanci fail per esempio è un motivo per mantenere le cose come stanno, inoltre lasciano la libertà di gestire diversamente gli errori in diversi posti del programma...

Questo discorso mi sta bene.

L'importante e' che qualunque cosa si decida, in caso di errore il gioco si inchiodi e l'origine del problema sia chiara e ben documentata.

Per i dettagli implementativi del linguaggio, decidete pure voi, la cosa piu' semplice e elegante va bene.

[VICIUS]

Originariamente inviato da cisc

[...]ammazione, ovvero casi che normalmente non dovrebbero verificarsi ma che è bene segnalare correttamente nel caso si verifichino anche per non avere sorprese in seguito...

Perfetto! È proprio quello che mi serviva.

ciao

[71104]

adesso all'improvviso ti piacciono di nuovo

[VICIUS]

Originariamente inviato da 71104

adesso all'improvviso ti piacciono di nuovo

Se devo fare try/catch ovunque preferisco non usarle. Ora pero che le ho convertitein delle RuntimeException posso usarle come voglio io quindi mi piaciono

Giusto per passare il tempo con un po di statistiche. Per ora abbiamo un code coverage pari al 92,1% con i test. Se riesco a capire come esportare tutto su un report ve lo pubblico da qualche parte

ciao

[cisc]

scusami, ma convertire tutte le eccezioni in runtime exception non mi sembra una soluzione elegante, è come dire che se non c'è la texture da visualizzare te ne freghi!! a parte il fatto che il try...catch non mi sembra introdurre tutta quella difficoltà di lettura del codice di cui parli, a me sembra ovvio che in certi casi (tipo mancanza della texture) devi catturare l'errore e gestirlo, tu dicevi di aggiungere direttamente nel codice dove viene lanciata l'eccezione un Util.fatalError, perchè il gioco deve terminare quando manca la texture, ma ciò IMHO toglie flessibilità nella gestione degli errori, perchè non utilizzare al meglio gli strumenti offerti dal linguaggio?

[cionci]

C'è un errore nel file del progetto:
Unbound classpath variable: 'CLOVER_RUNTIME' in project Diamonds

[VICIUS]

Originariamente inviato da cisc

scusami, ma convertire tutte le eccezioni in runtime exception non mi sembra una soluzione elegante, è come dire che se non c'è la texture da visualizzare te ne freghi!! a parte il fatto che il try...catch non mi sembra introdurre tutta quella difficoltà di lettura del codice di cui parli, a me sembra ovvio che in certi casi (tipo mancanza della texture) devi catturare l'errore e gestirlo, tu dicevi di aggiungere direttamente nel codice dove viene lanciata l'eccezione un Util.fatalError, perchè il gioco deve terminare quando manca la texture, ma ciò IMHO toglie flessibilità nella gestione degli errori, perchè non utilizzare al meglio gli strumenti offerti dal linguaggio?

Non sono d'accordo. Per ora questa mi sembra la piu flessibile. Ci permette di scrivere codice senza dover scrivere le try/catch quando non ci servono (il 99% delle volte). Ad esempio è possibile accedere a config senza fare assurdi controlli oppure caricare una texture senza gestire ogni volta TextureNotFoundException. Se vogliamo gestirle in un punto particolare possiamo ancora farlo inserendo appunto try/catch. Se non vengono gestite arivano alla jvm che termina il programma stampando il messaggio.

ciao

[VICIUS]

Originariamente inviato da cionci

C'è un errore nel file del progetto:
Unbound classpath variable: 'CLOVER_RUNTIME' in project Diamonds

Colpa mia. Clover si deve essere infiltrato durante un commit

ciao