Visualizzazione dei risultati da 1 a 9 su 9
  1. #1

    Problema gestione eccezioni mediante blocco try-catch

    Salve a tutti, vi spiego il mio problema.
    Sto realizzando in java un programma che sta in ascolto su una directory, e da questa directory prendo solo file .txt contenenti codice xml. Il mio problema sta nel gestire particolari situazioni di errore come per esempio xml formattato male oppure non presente. Di seguito vi posto la porzione di codice con cui sto provando a gestire l'errore:

    for(int j=0;j<fls.length;j++){
    File file=fls[j];
    //renameMalformedFile(file);
    try {
    SAXBuilder builder = new SAXBuilder();
    Document document =(Document) builder.build(file);
    Description= (document.getRootElement().getChild("DESCRIZIONE") .getValue());
    Title= (document.getRootElement().getChild("TITOLO").getV alue());
    Duration= (document.getRootElement().getChild("DURATA").getV alue());
    }catch (JDOMException e) {
    e.printStackTrace();
    renameMalformedFile(file);
    }catch (IOException e) {
    e.printStackTrace();
    }

    ........
    }
    Se l'xml è formattato bene il programma va ma, la cosa strana(per me), è che nel caso in cui va nel catch il programma passa per il metodo renameMalformedFile(file), lo esegue ma non va a buon fine(rinomino il file in modo k non sia piu processato), mentre, facendo una prova l'ho messo all'inizio del try (come vedete è commentato) funziona e rinomina il file, mi spiegate il perchè di questo comportamento?
    Grazie a tutti.

  2. #2
    Utente di HTML.it L'avatar di Freax
    Registrato dal
    Jul 2006
    Messaggi
    460
    posta il codice nei tag giusti, per quanto riguarda l'errore non vedo nessun
    codice:
    throw
    e questa mancanza rende operativo solo il blocco try, il catch senza una eccezione da gestire non serve a nulla; almeno da quello che ho studiato sino ad ora e che ho avuto modo di sperimentare.

    l'istruzione ( o per meglio dire, la struttura di controllo delle eccezioni ) try-throw-catch è incompleta.

  3. #3
    Come ti dicevo l'errore lo introduco io passando un file vuoto, ma quello che non mi torna è il fatto che il programma entra nel catch passa per il metodo con cui intendo gestire l'errore ma in realtà quel metodo non fa nulla, mentre se lo eseguo fuori dal blocco funziona. Secondo te devo aggingere la clausula throws? ma non sono modi differenti di trattare le eccezioni?

  4. #4
    il codice (più leggibile ):

    codice:
    for(int j=0;j<fls.length;j++){
    File file=fls[j];
    //renameMalformedFile(file);//in questa posizione funziona
    
    try { 
          SAXBuilder builder = new SAXBuilder();
          Document document =(Document) builder.build(file);
          Description= (document.getRootElement().getChild("DESCRIZIONE").getValue());
          Title= (document.getRootElement().getChild("TITOLO").getValue());
          Duration= (document.getRootElement().getChild("DURATA").getValue());
    }catch (JDOMException e) {
           e.printStackTrace();
           renameMalformedFile(file);//metodo invocato ma k non ha effetto(rinominare file)
      }catch (IOException e) {
          e.printStackTrace();
        }
    
    ........
    }

  5. #5
    Utente di HTML.it L'avatar di Freax
    Registrato dal
    Jul 2006
    Messaggi
    460
    Originariamente inviato da costangelo81
    Come ti dicevo l'errore lo introduco io passando un file vuoto, ma quello che non mi torna è il fatto che il programma entra nel catch passa per il metodo con cui intendo gestire l'errore ma in realtà quel metodo non fa nulla, mentre se lo eseguo fuori dal blocco funziona. Secondo te devo aggingere la clausula throws? ma non sono modi differenti di trattare le eccezioni?
    aspetta un attimo, hai scritto in maniera impropria una struttura di controllo, il fatto che il programma ti funzioni lo devi al fatto che il tuo programma sia sintatticamente e lessicalmente corretto, cioé è formalmente corretto, il problema è che non ha logica.

    La logica di un try-throw-catch te la detta all'inizio il throw e la sviluppa poi il catch.

    tu stai dicendo, nel tuo programma:

    codice:
    cara VM prova a fare così{
    }
    se ti lancio una eccezione di tipo JDOMException fai questo {
    }
    se ti lancio una eccezione di tipo IOException fai questo {
    }
    e a questo punto dimmi, dov'è che crei i 2 oggetti di tipo IOException o di tipo JDOMException ?
    risposta: da nessuna parte.

    in quale punto del codice indichi una condizione per la quale deve sollevarsi una eccezione?
    risposta: da nessuna parte.

    in quale punto del codice indichi non solo la condizione ma cosa vuoi che avvenga al verificarsi di quella condizione?
    risposta: da nessuna parte.

    un esempio di come va usata questa struttura di controllo è il seguente

    codice:
    cara VM prova a fare così{
    ...
    if ( numero<0 ) throw new Exception("questo programma non lavora con numeri negativi!");
    ...
    }
    se ti lancio una eccezione di tipo Exception che chiamo come ti indico tra parentesi fai questo {
    ...
    System.out.println( eccezione.getMessage() );
    ...
    }
    con la sola sintassi java verrebbe qualcosa del tipo

    codice:
    try{
    ...
    if ( numero<0 ) throw new Exception("questo programma non lavora con numeri negativi!");
    ...
    }
    catch ( Exception eccezione ) {
    ...
    System.out.println( eccezione.getMessage() );
    ...
    }
    il metodo getMessage() è ereditato da tutti gli oggetti che rappresentano eccezioni, che sono creati da throw, quindi ce l'hai sempre disponibile in questi casi, e da come output quello che passi come stringa al metodo costruttore nel throw.

  6. #6
    Ah.. pensavo di non dover essere io a dire qual'è la condizione da verificarsi, visto che nei catch mi riferivo sempre all'eccezione di livello più alta, per spiegarmi meglio :

    codice:
    org.jdom.input.JDOMParseException: Error on line 3 of document file:/C:/FtpHome/VIDEO_1000000.txt: Premature end of file.
    	at org.jdom.input.SAXBuilder.build(SAXBuilder.java:465)
    	at org.jdom.input.SAXBuilder.build(SAXBuilder.java:810)
    	at org.jdom.input.SAXBuilder.build(SAXBuilder.java:789)
    	at receiver.DirectoryPoller.runCycle(DirectoryPoller.java:386)
    	at receiver.DirectoryPoller.run(DirectoryPoller.java:322)
    Caused by: org.xml.sax.SAXParseException: Premature end of file.
    	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
    	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
    	at org.jdom.input.SAXBuilder.build(SAXBuilder.java:453)
    	... 4 more
    Caused by: org.xml.sax.SAXParseException: Premature end of file.
    	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
    	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
    	at org.jdom.input.SAXBuilder.build(SAXBuilder.java:453)
    	at org.jdom.input.SAXBuilder.build(SAXBuilder.java:810)
    	at org.jdom.input.SAXBuilder.build(SAXBuilder.java:789)
    	at receiver.DirectoryPoller.runCycle(DirectoryPoller.java:386)
    	at receiver.DirectoryPoller.run(DirectoryPoller.java:322)
    Caused by: org.xml.sax.SAXParseException: Premature end of file.
    	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
    	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
    	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
    	at org.jdom.input.SAXBuilder.build(SAXBuilder.java:453)
    	at org.jdom.input.SAXBuilder.build(SAXBuilder.java:810)
    	at org.jdom.input.SAXBuilder.build(SAXBuilder.java:789)
    Lui come primo salta per l'eccezione
    codice:
     org.jdom.input.JDOMParseException
    quindi facendo il catch per
    codice:
     JDOMException
    pensavo di intercettarla visto che si tratta dell'eccezione a salire.
    Comunque grazie per le risposte.

  7. #7
    Utente di HTML.it L'avatar di Freax
    Registrato dal
    Jul 2006
    Messaggi
    460
    Originariamente inviato da costangelo81
    Ah.. pensavo di non dover essere io a dire qual'è la condizione da verificarsi, visto che nei catch mi riferivo sempre all'eccezione di livello più alta, per spiegarmi meglio :

    codice:
    //
    Lui come primo salta per l'eccezione
    codice:
     org.jdom.input.JDOMParseException
    quindi facendo il catch per
    codice:
     JDOMException
    pensavo di intercettarla visto che si tratta dell'eccezione a salire.
    Comunque grazie per le risposte.
    si, ma c'è differenza nel creare un oggetto di tipo JDOMException e scrivere una condizione per la quale lanciare throw che crei un oggetto di tipo JDOMException; così possono accadere le seguenti cose:

    - la condizione è vera quindi, come sempre, ( come accade quindi non solo in un try-throw-catch ma anche in un normalissimo if ) viene eseguito il blocco di codice che segue
    - nel blocco di codice che segue c'è throw
    - viene creato l'oggetto che rappresenta l'eccezione
    - il blocco try viene interrotto
    - la VM, interrotto il blocco try, passa a censire tutti i catch, se si trova un catch che accetti come argomento un tipo uguale a quello che rappresenta l'eccezione sollevata allora viene eseguito quel catch
    - se nessun blocco catch accetta come argomento un oggetto dello stesso tipo dell'oggeto che rappresenta l'eccezione semplicemente nessun catch viene eseguito

    se nel blocco try non sollevi nessuna eccezione, il blocco try viene eseguito normalmente, i blocchi catch successivi non vengono eseguiti perché non avendo sollevato nessuna eccezione nel blocco try per la VM tutto è andato bene, quindi quei blocchi catch esistono ma non verranno mai attuati da una eccezione.

    inoltre, per mia esperienza, cerca di dare nomi diversi ai vari oggetti che rappresentano le eccezioni, è vero che una volta lanciata i vari catch si basano solo sul tipo e non sul nome per censire gli oggetti da accettare come argomento/i, ma è meglio evitare:
    A) nomi poco significativi
    B) lo stesso nome per 2 cose diverse che rappresentano 2 cose diverse

    EDIT: in sintesi, prima di fare un catch devi sempre interrompere il blocco try con un throw; altrimenti puoi avere gli oggetti che vuoi, del tipo che vuoi, ma viene eseguito solo il try nel migliore dei casi.

  8. #8
    OOK Molto gentile, seguirò i tuoi consigli.

  9. #9
    Moderatore di Programmazione L'avatar di LeleFT
    Registrato dal
    Jun 2003
    Messaggi
    17,320
    Originariamente inviato da Freax
    posta il codice nei tag giusti, per quanto riguarda l'errore non vedo nessun
    codice:
    throw
    e questa mancanza rende operativo solo il blocco try, il catch senza una eccezione da gestire non serve a nulla; almeno da quello che ho studiato sino ad ora e che ho avuto modo di sperimentare.

    l'istruzione ( o per meglio dire, la struttura di controllo delle eccezioni ) try-throw-catch è incompleta.
    Non ho capito cosa tu intenda dire, ma non è affatto necessario che vi sia un'istruzione throw affinchè venga sollevata un'eccezione e gestita, di conseguenza, da un blocco catch. Almeno, non da parte del programmatore che l'eccezione la vuole solo gestire...

    codice:
    try {
       metodoCheSollevaEccezione();
    } catch (Exception e) {
       e.printStackTrace();
    }
    Banalmente, questo codice solleva e intercetta un'eccezione:

    codice:
    public class Eccezione {
       public static void main(String[] args) {
          try {
    
             int risultato = 8 / 0;
    
          } catch (Exception e) {
             System.out.println("Ho sollevato un'eccezione!!");
             e.printStackTrace();
          }
       }
    }
    Ciao.
    "Perchè spendere anche solo 5 dollari per un S.O., quando posso averne uno gratis e spendere quei 5 dollari per 5 bottiglie di birra?" [Jon "maddog" Hall]
    Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.