Comment gérer les exceptions localisées ?

Question

Il semble que je sois toujours à la croisée des chemins lorsque je ne sais pas exactement comment traiter une exception sans la renvoyer à l'appelant.

Y a-t-il une meilleure façon de gérer la situation ci-dessous ?

private DataHandler retrieveFromGridFS(ObjectId id) throws IOException
{
    GridFS gridFS = new GridFS(getDBReference());        
    GridFSDBFile out = gridFS.find(id);

    File temp = File.createTempFile(
            (String)out.getMetaData().get("productName"), 
            (String)out.getMetaData().get("productType"));

    out.writeTo(temp);

    return new DataHandler(new FileDataSource(temp));        
}

Ce qui précède private peut lancer un IOException .

En utilisant cette méthode de la manière suivante :

public DataHandler retrieveProduct(String productId) throws IOException
{
    ObjectId id = new ObjectId(productId);
    DataHandler handler = null;

    try
    {
        handler = retrieveFromGridFS(id);
    }
    catch(IOException ex)
    {
        logger.error(ex);
        throw new IOException("A problem occurred retrieving product.");
    }

    return handler;
}

Je suis obligé de relancer pour ne pas risquer de retourner null.

Answer 1

Cela dépend totalement.

D'abord, voulez-vous vraiment faire percoler une IOException aux couches supérieures, ou voulez-vous encapsuler les diverses exceptions qui peuvent se produire aux couches inférieures dans une exception spécifique à l'application ?

Devez-vous être en mesure de récupérer cette exception ? Si non, est-ce qu'un RuntimeException plus approprié ? (Même si vous faire Si vous avez besoin que l'exception soit récupérable, travaillez-vous dans un environnement qui prévoit un traitement déclaratif des exceptions à un niveau élevé ?)

Serait-il plus judicieux d'utiliser un NullObject pour éviter de retourner un null ?

(Etc. :)

Answer 2

En général, il faut attraper l'exception si vous pouvez réagir à l'événement qui s'est produit . Par exemple, disons que vous avez un code pour réessayer les connexions en cas d'échec. Vous pourriez alors avoir une boucle qui attrape l'exception IOException et réessaie x fois. L'appelant ci-dessus ne se soucie pas des échecs sous-jacents.

Lorsqu'une exception se produit et que vous ne pouvez pas la gérer, vous ne le faites pas. Essentiellement, vous vous renvoyez la balle.

Ces derniers temps, j'ai eu tendance à éviter de relancer les exceptions, car d'autres exc objects dans la plupart des cas. J'ai découvert par expérience que cela n'apporte pas vraiment de valeur ajoutée la plupart du temps.

Answer 3

Quoi ? Il me semble que retrieveProduct est juste une fonction pratique pour faire ce que retrieveFromGridFS mais avec un String comme identifiant au lieu d'un ObjectId. Ainsi, l'ensemble des exceptions qu'il peut soulever ne devrait-il pas être le même que celui de la fonction retrieveFromGridFS ?