locked
Catching unhandled exceptions in VB.net on CE 4.2 running on ARMV4 RRS feed

  • Question

  • My application writes diagnostic information to a memory key plugged into it's device and I need to be able to handle the situation where the memory key is removed in mid-write.  The IOException that is sometimes thrown (it's sort of a timing thing) becomes an unhandled exception and the system has to be rebooted.  That is bad enough, but at least a person is standing by the device to do the reboot.  I suspect that, statistically, I'm going to get IOExceptions from those writes to the memory key even if it hasn't been fiddled with, and that will bring the system down with no one nearby to reboot it.  Ultimately, not being able to write out our diagnostic file should is NOT a show-stopper.

    My app is a VB.NET forms app. developed in VS2003 and deployed to a CE 4.2 OS running on ARMV4.  What I've tried:

    1) ------------------------------------

    As suggested in http://devcity.net/Articles/60/1/unhandled_exceptions.aspx

       Dim currentDomain As AppDomain = AppDomain.CurrentDomain
         'for regular unhandled stuff
       AddHandler currentDomain.UnhandledException, AddressOf MYExceptionHandler
         'for threads behind forms
       AddHandler Application.ThreadException, AddressOf MYThreadHandler

    etc...

    Why I can't get it to work:  Intellisense can't resolve AppDomain.CurrentDomain.  Does this concept just not exist for my device/OS combination?

    Also, in the event handlers from the example (referred to by the article above)  I need to implement:

    Private Sub MYExceptionHandler(ByVal sender As Object, ByVal e As UnhandledExceptionEventArgs)
         ' code here
    End Sub

    But Intellisense can't resolve UnhandledExceptionEventArgs

    2) ------------------------------------

    System.IO.FileSystemWatcher -I thought this might help, but my IDE can't find it either and it may not be able to tell me such fundamentals as whether or not the "hard disk" (as a memory key is identified by CE 4.2) is in place or not.

    My main questions relate to the fundamental task I'm trying to achieve (handling the IOException), but I'm a little mystified about functionality gaps in .NET 1.1 for my device.

    Thanks!

     

    Wednesday, April 21, 2010 1:48 PM

Answers

  • Hi,

    The AppDomain.UnhandledException Event is supported in .NET CF 2.0 and above :-

    http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(VS.80).aspx

    Thanks

    Paul Diston


    http://www.smartmobiledevice.co.uk/
    • Proposed as answer by Paul Diston Thursday, April 22, 2010 12:34 PM
    • Marked as answer by warrentang Monday, April 26, 2010 3:33 AM
    Thursday, April 22, 2010 7:11 AM
  • I believe you should be able to handle this exception with a TRY/CATCH around the write calls to the file.  You should do this and handle the exception gracefully if possible.  Also, note that although the documentation says nothing about it,  FileStream.Close() can throw an IOException if the media has been removed.   So I would not recommend calling in your try catch unless you also try catch the close.

    Handling unhandled exception should be a last resort.  I do use it myself, but it should only happen if everything else has gone seriously wrong.  Also,  handlers for unhandled exception should attempt to execute quickly, as your program is about to die... you will not be able to display new forms or messages to the user.  I actually use a separate assembly to report errors and in my unhandled exception I create a new AppDomain and tell it to execute my error reporting process.

    • Marked as answer by warrentang Monday, April 26, 2010 3:33 AM
    Thursday, April 22, 2010 2:41 PM

All replies

  • Hi,

    The AppDomain.UnhandledException Event is supported in .NET CF 2.0 and above :-

    http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(VS.80).aspx

    Thanks

    Paul Diston


    http://www.smartmobiledevice.co.uk/
    • Proposed as answer by Paul Diston Thursday, April 22, 2010 12:34 PM
    • Marked as answer by warrentang Monday, April 26, 2010 3:33 AM
    Thursday, April 22, 2010 7:11 AM
  • Thanks Paul,

    Following your link (to content that I'm sure I've brushed over before), I now see the magic words about compact framework support at the bottom.  And I'm always telling my users to "read the documentation"...

     

    Thursday, April 22, 2010 12:22 PM
  • I believe you should be able to handle this exception with a TRY/CATCH around the write calls to the file.  You should do this and handle the exception gracefully if possible.  Also, note that although the documentation says nothing about it,  FileStream.Close() can throw an IOException if the media has been removed.   So I would not recommend calling in your try catch unless you also try catch the close.

    Handling unhandled exception should be a last resort.  I do use it myself, but it should only happen if everything else has gone seriously wrong.  Also,  handlers for unhandled exception should attempt to execute quickly, as your program is about to die... you will not be able to display new forms or messages to the user.  I actually use a separate assembly to report errors and in my unhandled exception I create a new AppDomain and tell it to execute my error reporting process.

    • Marked as answer by warrentang Monday, April 26, 2010 3:33 AM
    Thursday, April 22, 2010 2:41 PM
  •  

    Thanks, and sorry about the delay in this note.  Your reply gets me to look at unhandled exceptions in a different way -I'll be more diligent in the try catch blocks.  At the minimum, is it enough to catch the exception at the level (subroutine/function) it occurs, even if I do nothing about it?  Remember, the particular IOException I'm worried about isn't fatal to my program operation.

    Thanks

    Wednesday, May 5, 2010 12:40 PM
  • yeah if it doesn't cause any unwanted side effects there are times when you can leave the catch block empty.  Sometimes you may want to warn the user something failed, sometimes you may want to do something else... it depends on what you are doing.
    Wednesday, May 5, 2010 2:28 PM