I have a utility method which reads an xml file and converts to string as below:

public static String readFile(String xmlFileName) throws IOException, DocumentException{
        String xmlMsg = null;
        Resource resource = null;
        InputStream inputStream = null;
        try{
            resource = new ClassPathResource(xmlFileName);
            inputStream = resource.getInputStream();
            SAXReader reader = new SAXReader();
            Document doc = reader.read( inputStream );
            xmlMsg = doc.asXML();
        }finally{
            if(inputStream != null){
                inputStream.close();
            }
        }
        return xmlMsg;
    }


Is it a bad idea if I catch the DocumentException in the above code and rethrow it as below:

public static String readFile(String xmlFileName) throws IOException, DocumentException{
        String xmlMsg = null;
        Resource resource = null;
        InputStream inputStream = null;
        try{
            resource = new ClassPathResource(xmlFileName);
            inputStream = resource.getInputStream();
            SAXReader reader = new SAXReader();
            Document doc = reader.read( inputStream );
            xmlMsg = doc.asXML();
        }catch (DocumentException e){
           throw new DocumentException("some message");
        }finally{
            if(inputStream != null){
                inputStream.close();
            }
        }
        return xmlMsg;
    }


So, is it a bad idea to leave the responsibility of handling the DocumentException to the caller?


Question: Why was the winner of the AES competition not a Feistel cipher?
Answer: As a page at ibm.com indicates, there could have been a bit of a "contra" attitude against Feistel ciphers thanks to DES having seen the first breaks in it's security etc. 


  Down with the Feistel structure!
  
  In most ciphers, the round transformation has the well-known Feistel structure. In this structure typically part of the bits of the intermediate State are simply transposed unchanged to another position. (An example of this linear kind of structure are those tables we discussed back in the DES discussion that substitute bits by a fixed tabular means.) The round transformation of Rijndael does not have this venerable Feistel structure. Instead, the round transformation is composed of three distinct invertible uniform transformations, called layers. ("Uniform" here means that every bit of the State is treated in a similar way.)
  
  The linear mixing layer guarantees high diffusion over multiple rounds. The non-linear layer uses parallel application of S-boxes that have the desired (hence optimum) worst-case nonlinearity properties. The S-boxes are non-linear. That's the key conceptual difference between DES and Rijndael…


So, I guess one of the reasons they chose a non-Feistel cipher could well have been that they wanted to guarantee higher security through higher diffusion etc. while hoping that — in case Feistel ciphers should collapse sooner than expected — the next crypto they were about to recommend wouldn't automatically join in and break down too.

Serpent for example was designed so that all operations can be executed in parallel, using 32 1-bit slices. While this maximizes parallelism, it also allowed immediate use of the extensive cryptanalysis work performed on DES. A good reason not to give Serpent that final go and prefer "something else" (most probably because Serpent's origins were too close to a theoretically broken Feistel — DES).

This would also go in canon with what @thomas-pornin mentioned in the first lines of his great answer.