Segue dal precedente post. Un servizio windows deve essere resistente agli errori, per questa ragione effettuo un wrap del metodo start in un blocco try catch, e nel gestore delle eccezioni effettuo un trace il più dettagliato possibile dell'eccezione, questo perché deve essere assolutamente evidente dal trace capire perchè il servizio non può partire, ma questo spesso non è sufficiente affinché il servizio si dica robusto.
Ad esempio, lavorando con applicativi web spesso mi trovo di fronte ad operazioni asincrone abbastanza onerose che preferisco far fare ad un servizio in background, durante l'elaborazione delle pagine web vengono immessi in una tabella delle istruzioni per dei task che debbono essere effettuati da un servizio. Il codice del servizio quindi gira con un timer, ad ogni esecuzione legge dalla tabella tutti i task non completati, poi effettua un ciclo e per ogni task chiama una funzione apposita, che effettua il task stesso. Affinché il servizio rimanga attivo proteggo con un try catch il blocco che esegue il singolo task. Al sopraggiungere di una eccezione eseguo due operazioni: effettuo un log che viene mandato per mail al gruppo di sviluppo e marco il record del task con un flag che mi indica che quel task ha generato eccezione. In questo modo si può andare nel db e vedere tutti i task che hanno provocato un'eccezione e si possono rieseguire, magari dentro un debugger, per capire meglio cosa è andato storto.
L'avere wrappato la singola chiamata al task dentro un try catch fa si che un errore che si genera in un task non interrompa l'esecuzione degli altri task. Un altro consiglio è cercare di validare nella maniera più approfondita possibile gli input del servizio prima di eseguire ogni operazione, ma se si è inserita una buona infrastruttura di log e si sono gestite le eccezioni in modo corretto il servizio non crollerà mai e in presenza di dati strani o errati verranno generate eccezioni con tempestive segnalazioni per mail in modo da permettere una correzione immediata.
Alk.