Sometimes, we may encounter corrupted files, or files with unknown extensions.
Will be good if GroupDocs.Conversion can fail gracefully when it encounters such situations.
Attached is a simple text file with filename “unknown.ext”:
sample.zip (211 Bytes)
Using the following piece of code:
GroupDocs.Conversion.FluentConverter.Load("unknown.ext").ConvertTo("unknown.pdf").Convert();
It will throw exception:
Unhandled Exception: GroupDocs.Conversion.Exceptions.GroupDocsConversionException: Exception of type 'System.OutOfMemoryException' was thrown. ---> System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at System.IO.MemoryStream.set_Capacity(Int32 value)
at System.IO.MemoryStream.EnsureCapacity(Int32 value)
at System.IO.MemoryStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at #=zrQ6_h4UFvAKeklZwiAJuWbC8d9ruwsNhkqyEgRo=.#=zDwEkrHY=()
at #=zrQ6_h4UFvAKeklZwiAJuWbC8d9ruwsNhkqyEgRo=.#=zBUUz38NRe6pH(UInt32 #=zTHPuERo=, UInt32 #=zX6R5N1k=)
at #=z2SjnS366aNpomxa3dg0xQxBblm5vUvUHuQ8$gHw=.#=zPn1zWWo=(Stream #=zprx9fQwmEYm0, Stream #=zr3sW9y78JnlT, Int64 #=z6LKql5U=, Int64 #=zrKH$FEo=, #=zcEtrG94Em$R$ilhRmzzQZup5qZlt_$cE$A== #=zICd4QTs=, Boolean #=zN1MUkMyX_nj1)
at Aspose.Zip.LZMA.LzmaArchive.Extract(Stream destination)
at ..MoveNext()
at ? ..MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at .(Exception )
at .(Object )
at .(MethodBase , Boolean)
at .( )
at . ( , )
at . ()
at .(Boolean )
--- End of stack trace from previous location where exception was thrown ---
at .(Exception )
at .(Object )
at . ()
at .?( , )
at . ()
at .(Boolean )
--- End of stack trace from previous location where exception was thrown ---
at .(Exception )
at .(Object )
at . ()
at .(Object , UInt32)
at .(Boolean )
at .(Boolean )
at . ()
at .(Object[] , Type[], Type[] , Object[] )
at .(Stream , String, Object[] , Type[] , Type[] , Object[] )
at (Stream , String, Object[] )
at ? .MoveNext()
at (CancellationToken )
at .()
at System.Threading.Tasks.Task.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
--- End of inner exception stack trace ---
at ..(Exception )
at System.AggregateException.Handle(Func`2 predicate)
at .(CancellationToken )
at .Convert(CancellationToken )
Hello @jarrodwee ,
Thank you for reaching out. We will investigate this issue as soon as possible and get back to you once we have any updates.
In the meantime, could you please clarify what kind of result or behavior you would expect from GroupDocs.Conversion for .NET in this situation?
For example, would you prefer to have a more standardized message in case of such an exception, or would you rather have the ability to continue processing by catching such exceptions through regular logging?
Will be best if GroupDocs.Conversion actually catches the exception and let itself continue to the documentCompleted action handler.
In the documentCompleted handler, there’s a ConvertedStream in the ConvertedContext which can be set to null in such situation, i.e. to indicate that conversion was not successful. ConvertedFormat should also be set to FileType.Unknown as well.
Perhaps additional properties can also be added to ConvertedContext, e.g. the Exception itself, or otherwise, the error message and/or stacktrace to let the caller know the possible failure reason.
The above is especially important for recursive conversion whereby child documents are also converted. Any exception due to the conversion of one child should be caught and let the other children conversion continue on.
@jarrodwee ,
Thank you for sharing your thoughts on this matter.
We have logged this issue in our internal tracking system under the ID CONVERSIONNET-7846.
We will get back to you once we complete a more detailed investigation.
Retesting with the latest GroupDocs.Conversion 25.7 via GroupDocs.Total.NETFramework 25.7 using the same sample test.
Noted that the original code needs to include the new OnConversionFailed to be specified, else it says:
1>C:\Projects\NETFrameworkGroupDocs\NETFrameworkGroupDocs\Program.cs(299,147,299,154): error CS1061: 'IConversionOptionsOrHandlerSetup' does not contain a definition for 'Convert' and no accessible extension method 'Convert' accepting a first argument of type 'IConversionOptionsOrHandlerSetup' could be found (are you missing a using directive or an assembly reference?)
Updated code which compiles okay:
GroupDocs.Conversion.FluentConverter.Load("unknown.ext").ConvertTo("unknown.pdf").OnConversionFailed((context, exception) =>
{
Console.WriteLine($"OnConversionFailed: {exception.Message}\n{exception.StackTrace}");
}).Convert();
Noted also that the above error handler doesn’t trigger and the below exception is thrown instead of the previous Out of Memory exception in the earlier version - seems like it is trying to load Aspose.PSD?
Unhandled Exception: GroupDocs.Conversion.Exceptions.GroupDocsConversionException: The type initializer for ' ' threw an exception. ---> System.TypeInitializationException: The type initializer for ' ' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Aspose.PSD, Version=25.6.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56' or one of its dependencies. The system cannot find the file specified. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Aspose.PSD, Version=25.4.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56' or one of its dependencies. The system cannot find the file specified.
--- End of inner exception stack trace ---
at ..cctor()
--- End of inner exception stack trace ---
at .()
at GroupDocs.Conversion.FileTypes.FileType()
at GroupDocs.Conversion.FileTypes.FileType.()
at GroupDocs.Conversion.FileTypes.FileType.FromExtension(String fileExtension)
at GroupDocs.Conversion.FileTypes.FileType.FromFilename(String fileName)
at ..(ConvertContext )
at .(Exception , ConverterSettings, )
at (CancellationToken )
at .()
at System.Threading.Tasks.Task.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
--- End of inner exception stack trace ---
at ..(Exception )
at System.AggregateException.Handle(Func`2 predicate)
at .(CancellationToken )
at .Convert(CancellationToken )
Hello @jarrodwee ,
We sincerely apologize that you have encountered this issue after the release of the new feature. Please allow us some time to thoroughly review your scenario. We will get back to you with the results as soon as possible.
Hello @jarrodwee ,
We were able to reproduce this issue on our side. A corresponding ticket with ID TOTALNET-280 has been created in our tracking system, and we will need some additional time to investigate the root cause in more detail. We would also like to clarify whether you have tried testing this functionality with the standalone GroupDocs.Conversion for .NET 25.7 library, since we have confirmed that it works there as expected.
Removing all Nuget packages and adding only GroupDocs.Conversion for .NET 25.7, the OnConversionFailed error handler does get triggered with the Out of Memory exception.
Removing all Nuget packages and adding only GroupDocs.Total for .NET 25.7, it now behaves as expected, the OnConversionFailed handler is triggered same as above.
Noted previously that I was also testing GroupDocs.Metadata - and by simply adding that Metadata package back into the project, I now see the Aspose.PSD loading exception instead.
It seems that the existence of the GroupDocs.Metadata.dll or perhaps some other DLLs which Metadata depends on might be causing this odd behaviour.
Hello @jarrodwee ,
Thank you for sharing this information with us. We will certainly use it to speed up the investigation process. Please rest assured that we will contact you as soon as we have any results.
@jarrodwee
I have reproduced the issue you described. When I have this two dependencies in my project:
<PackageReference Include="GroupDocs.Total.NETFramework" Version="25.7.0" />
<PackageReference Include="GroupDocs.Metadata.NETFramework" Version="25.8.0" />
I get Could not load file or assembly... exception.
This happens because GroupDocs.Total and other GroupDocs products do not sync the internal libraries versions and when products depend on different internal library version this exception happens. Not in all the cases but it fails.
To address this issue we’re building GroupDocs.Total and GroupDocs.Total.NETFramework from the sources of all of the GroupDocs products combined and recommend to use Total instead of set of the products in their applications as more reliable alternative.
Unfortunately, we haven’t found another way to address this issue except App Domain, Process or Service isolation. Isolation solves the issues but requires more complex infrastructure.
Thanks, no worries actually since the only reason why GroupDocs.Metadata.NETFramework was also present in the project was to test the latest GroupDocs.Metadata previously for other issues.
Going forward, will make sure not to include other individual GroupDocs packages when testing the Total package.
1 Like
@jarrodwee
Got it, thanks for the feedback. Have a nice day!