Aspose.Words exceptions serialization

Aspose.Words Product Family
1

I’m facing the same problem referred in this thread: I’m working in a client-server scenario, using .Net remoting to communicate from client to server.

If aspose.Words raises an Aspose.Words.UnsupportedFileFormatException, the client is not able to deserialize the exception and I get instead the following exception:

Dettagli eccezione: System.Runtime.Serialization.SerializationException: Impossibile trovare il costruttore richiesto per deserializzare un oggetto di tipo ‘Aspose.Words.UnsupportedFileFormatException’.

I’m working with Italian localized version of .Net framework, the corresponding English message should be something such

Exception detalis: System.Runtime.Serialization.SerializationException: Unable to find required constructor to deserialize an object of type ‘Aspose.Words.UnsupportedFileFormatException’.

Quoting from previous thread:

1. According to Microsoft “Designingn Custom Exceptions” guidelines "… An exception must be serializable to work correctly across application domain and remoting boundaries… (https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/ms229064(v=vs.100)).

Not sure, but using reflection it seems that UnsupportedFileFormatException (and also FileCorruptedException and IncorrectPasswordException) does not meet the guidelines specified by Microsoft, and therefore are not correctly handled when crossing remoting boundaries

I’m using Aspose.Words version 9.6.0.0 (I just noticed you have a 9.7 version available, but release notes don’t refer to any change in Exceptions serialization)

I’m working with Visual Studio 2008, .Net framework 3.5

Is this something is going to be fixed? or is there any workaround?

Thanks for help

Gian Paolo

2

Hi

Thank you for reporting the problem to us. Your request has been linked to the appropriate issue. You will be notified as soon as it is resolved.

As a temporary solution, you can try using DetectFileFormat method to determine whether the input file is in supported format and if not throw your own exception.

https://reference.aspose.com/words/net/aspose.words/fileformatutil/detectfileformat/

Best regards,

3

Thanks for the prompt answer.

The workaround you suggest may be quite weak: the DetectFileFormat documentation says:

Even if this method detects the document format, it does not guarantee that the specified document is valid. This method only detects the document format by reading data that is sufficient for detection. To fully verify that a document is valid you need to load the document into a Document object.

Meaning that an “UnsupportedFileFormatException” can be raised anyway.

I think I’m going to do something as

try
{
    //work with Aspose.Words
}
catch (UnsupportedFileFormatException exc)
{
    // manage exception somehow
}
catch (FileCorruptedException exc)
{
    // manage exception somehow
}
catch (IncorrectPasswordException exc)
{
    // manage exception somehow
}

Are there any other exception type that I can catch? (by the way, you could consider inherit all your exception types from a common “AsposeException”, so developpers can catch only the base type and not all the derived types)

Thanks again for the your help

Gian Paolo

4

Hi

Thanks for your request. Actually, Aspose.Words internally uses DetectFileFormat method when you open the document and if format is not detected (not supported), Aspose.Words throws UnsupportedFileFormatException. So if you check format before opening the document, you can prevent throwing UnsupportedFileFormatException.

Here you can find a list of exceptions that can be thrown upon loading a document:

https://reference.aspose.com/words/net/aspose.words/document/

Best regards,

5

Hi,

Thanks for pointing out to the exception serialization problem. I checked and the Aspose.Words exception classes are marked as [Serializable] it is certainly a defect that they actually fail to be serialized and we will fix this in the next version.

But I am still not so sure that creating a base class for our exception is a good idea. I think that exception classes should only be created if you are going to catch them and do something useful. Can you give me a good case and explanation where and why would you want to catch all Aspose.Words exceptions?

If you want to catch all Aspose.Words exceptions during opening of a document, then you need to remember that Aspose.Words can throw any .NET exception, not only its own. Aspose.Words can throw any of the exceptions that an underlying IO.Stream throws for example.

So if all Aspose.Words exceptions are serializable properly, maybe you don’t really have a need to catch them using a single base class? As one of the .NET guidelines says “Do not create and throw exceptions just to have you team’s exception”.

6

I agree with you, creating a base exception type would not be a great idea.

I was thinking to implement something such:

try
{
    // work with aspose
}
catch (AsposeBaseException exc)
{
    throw new SomeSerializableException();
}

leaving to the caller the proper handling of exception.

But the right way, it’s simply to have the exception correctly serialized as you say.

have you got an idea on when this fix will be released?

By the way, congratulation for your techsupport: it’s a great, when having a problem, posting it to the forum and get and answer in such a short time.

7

Hi

Thank you for additional information. The issue is already resolved in the current codebase. The fix will be included into the next version of Aspose.Words.

Aspose.Words releases are published regularly every 5-6 weeks. So the next version of Aspose.Words will come out in 3-4 weeks.

Best regards,

8

The issues you have found earlier (filed as 24522) have been fixed in this update.

This message was posted using Notification2Forum from Downloads module by aspose.notifier.