Getting ObjectDisposedException after changing DocumentSource

[Dean]

I have a simple RadPdfViewer declared in my UserControl:

    <t:RadPdfViewer Grid.Row="1" x:Name="PdfViewer" DocumentSource="{Binding Uri}" 
                    PreviewKeyDown="PdfViewer_OnPreviewKeyDown"
                    DocumentChanged="PdfViewer_OnDocumentChanged"/>

Randomly (although it appears that this exception does not occur if I wait for the current document to be fully rendered and the progress indicator to be removed by the RadPdfViewer) when "Uri" property in my VM (which is a simple string property) is changed to new Uri of some pdf file I get ObjectDisposedException with "Cannot access a closed file." message.

StackTrace:

   at System.IO.__Error.FileNotOpen()
   at System.IO.FileStream.get_Position()
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.PdfReader.Readers.PdfReaderBase.ReadInternal() in c:\TB\117\WPF_Scrum\Release_WPF\Sources\Development\Documents\Fixed\Core\FormatProviders\Pdf\PdfReader\Readers\PdfReaderBase.cs:line 174

Exception Detail:
System.ObjectDisposedException occurred
  HResult=-2146232798
  Message=Cannot access a closed file.
  Source=mscorlib
  ObjectName=""
  StackTrace:
       at System.IO.__Error.FileNotOpen()
       at System.IO.FileStream.get_Position()
       at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.PdfReader.Readers.PdfReaderBase.get_Position() in c:\TB\117\WPF_Scrum\Release_WPF\Sources\Development\Documents\Fixed\Core\FormatProviders\Pdf\PdfReader\Readers\PdfReaderBase.cs:line 55
  InnerException:

Could you please take a look?

[Alexander]

Hi Dean,

RadPdfViewer loads the documents asynchronously. When you change the DocumentSource before the document has loaded, the stream of the document is being closed but the loading continues and RadPdfViewer tries to access a closed stream. This is why an exception is being thrown. 

I hope this is helpful. Please, do not hesitate to contact us if you have any other questions.

Regards,
Alexander
Telerik

[Dean]

Thanks but what's the solution? I tried placing the try/catch block when setting the DocumentSource but the catch block code is never reached...

I tried catching the exception in DocumentChanged event as well but this exception is thrown before this event fires and I don't see any other RadPdfViewer event that looks like a good candidate for catching this exception...

Where exactly can I catch this exception?

I mean, you explained why the exception is thrown and that's all fine and dandy but not a word on how to handle it?

I'm just going through all the methods and events of RadPdfViewer and I just don't see a 'DocumentLoaded' property or event that would help me avoid this exception being thrown when DocumentSource is changed before the previous file finished loading...

There is 'DocumentSource.Loaded' event but this event cannot be subscribed to when RadPdfViewer is loaded because at that point DocumentSource is obviously null so where do you subscribe to it...

[Kammen]

Hi Dean,

Actually, this exception is handled by the DocumentSource, so the only reason you could see it is because you have enabled "Break when an exception is thrown" option. This exception should not affect your application's behavior at all.

Note that using exceptions is a common approach when you want to stop/cancel asynchronous operations so I cannot see any problem using it in this case as it is properly handled in the DocumentSource class.

Hope this answers your questions.

Regards,
Kammen
Telerik

[Dean]

Wow, you make it sound as if having the "Break when an exception is thrown" option enabled is something weird... isn't it exactly what every developer wants when debugging?

BTW, where exactly can I find this "little", unimportant, detail in your RadPdfViewer documentation?

Thanks,

Dean

[Iva Toteva]

Hi Dean,

Enabling the "Break  when an exception is thrown" option can indeed be useful in some cases. However, with this option the debugger will break even on handled exceptions such as the ObjectDisposedException (compared to the option "Break when an exception is user-unhandled"). Following up on one of your previous comments, trying to surround the code that is triggering the exception in a try/catch block will also not change the behavior of the application with this more defensive option.

Having in mind that you also agree that using exceptions internally is acceptable as long as they do not propagate to the users of the control as unhandled exceptions, what you can do is to uncheck the option for breaking on every occurrence of this specific exception.

When it comes to documenting this specifics of RadPdfViewer, we believe this is not required because it describes the particular implementation of the feature and not its use. Furthermore, it may cause greater confusion because developers will try to handle the exception themselves, which as pointed out is not required.

I hope you find this point of view valid.

Regards,
Iva Toteva
Telerik