I’m evaluating Aspose to handle some server-side document merging.
In your Java api, I’d like to suggest that you do not throw generic Exceptions. It makes it very difficult to determine what specifically went wrong when using the api. For example: Was the issue caused by a pre-97 Word doc? Data casting errors? Was the doc password protected?
All would be easy to recognize if there was some way to determine the cause of a problem - either through the use of a specific exceptions, or a way to find the reason via the exception - i.e. e.getAsposeReason(), which returns an int or an enumeration.
The only way for me to do this now is to inspect the message text for the exception you throw - which will definitely break if you change your messages.
Thanks…!
Hi,
Thank you so much for your suggestion. I will ask our Java developer to take a look at your post. From the .NET developer’s point of view, I must note that exceptions was designed exactly to avoid returning error code that was a common practice in COM and WinAPI. It is also not a good practice to implement a deep hierarchy of exceptions, one class per possible error, so error messages are still essential. However, I will leave this Java specific discussion for our Java developer who will reply to you shortly.
Right - just need visibility to the cause of an exception. I’ve my own opinions on the best way to do this, but I trust that you folks will do what is best for your application.
Thanks,
David
Hi, David,
You have raised an interesting issue. We are constantly looking for what we can improve in this area.
But, afraid, I do not understand fully what you asking for. Are you using the latest release of Aspose.Words for Java?
Aspose.Words for Java almost does not throw java.lang.Exception. It is left couple of places but they will be wiped out in the next release – thanks for reminding.
About exceptions you asked for. For pre-word97 documents we throw com.aspose.words.UnsupportedFileFormatException (as well as for wml, rtf (that not supported in java yet) or for any other unknown file formats). For bad passwords we throw java.lang.SecurityException(“The document password is incorrect.”). Class casting exceptions is a separate case: we either retranslating it untouched or wrapping it into com.aspose.words.PleaseReportException – this depends on context.
There are many runtime or io exceptions that we wrapping into com.aspose.words.PleaseReportException or com.aspose.words.FileCorruptedException. There are also many other runtime exceptions that we do not touch because such a wrapping could not add any additional info.
Any way, every exception that issued by Aspose.Words has its own message text that unambiguously identifies the exception.
Please, provide the more detailed explanation about generic Exceptions in Aspose.Words and what we can improve in this area. May be we have to provide additional documentation about exceptions that are thrown by Aspose.Words?
Best Regards,
For example, javadocs from your website say:**
Document
public Document(java.io.InputStream stream) throws java.lang.Exception
Opens an existing document from a stream. Parameters: stream - Stream where to load the document from.
The javadoc seems accurate (my IDE agrees), and those other concrete exceptions you’re describing aren’t shown in your online documentation. I’m using the latest jar.
Hi, David,
The Document ctor is a top of almost all Aspose.Words API. It accommodates all exceptions that translated from the lower levels. I think it will be not very handy if in the ctor signature will be listed 10-15 exceptions:)
About javadoc accuracy you right – it generated right after compilation. But we have great:) plans for the further javadoc improvement – we using ours own javadoc generator and therefore we can adjust it so the documentation will be closer to the Aspose.Words structure and particular features.
Best Regards,
Could you point me towards, or provide, a list of exceptions that could be thrown by these methods?
License.setLicense(String)
Document(InputStream)
Document.getMailMerge().execute(IMailMergeData)
Document.getMailMerge().executeWithRegions(IMailMergeData)
Document.save(OutputStream, int)
DocumentBuilder.moveToMergeField(String)
DocumentBuilder.insertField(String)
Hi, David,
Although I can manually collect almost all exceptions for methods you request, but this will be just a waste work for you and me: we will wipe out and reorganize aspose.words exceptions in the next release (thanks for your questions:) so this info quickly become out of date.
Regards,
That begs the next question then - when is the next release?
Thanks for your help on this!
…one reason I need this sort of information - I have to give our
end-users clear/concise reasons why their merge operation didn’t work.
Hi, David,
The next release is scheduled for June. It will contain html export module and, as usual, bugs fixes and improvements both ported from .Net and java-specific.
What kinds of problems encounter your users? You can retranslate it here and we will trying to resolve them together.
Best Regards,
At this point, only simple things like I described earlier. The ability to discern the reason for the exception is important for us - i.e. if a user tries to use a .docx document, for example, we depend on your library to tell us this in enough detail so that we can communicate this fact to a user.
It seems that you do throw good exceptions… they just aren’t documented clearly or at all.