1

Possibly an obvious question to some but couldn't find a duplicate.

I'm packaging the final version of a Windows Forms solution I've been working on and am getting it ready for online distribution. What are the best practices when doing so? We've already had some trouble with packaging the installation file and have run into hurdles to test the program on different PCs, both 32 and 64-bit included.

More specifically, should "throw;" commands be commented out or left in the final release? Would this expose any of the inner workings of the solution itself?

GroomedGorilla
  • 920
  • 2
  • 10
  • 30
  • 2
    Exceptions should be handled with an error log of some sort, otherwise you have almost no chance of fixing any bugs that arise – Sayse May 28 '14 at 13:34
  • All Exceptions should be handled ;) And it won't show anything important about inner code, it will just be a MessageBox saying f.e. "NullReferenceException" and the program will crash. – Kamil T May 28 '14 at 13:35

3 Answers3

2

Keep all of your exception handling intact.

Add an event to the starting form in the application, attaching to the Application.UnhandledException event. This will fire if an exception propogates up the stack.

This is the point to inform the user that the application has crashed. Log the error here and then abort gracefully.

Your point about revealing internals, thats up to you to decide. You can obfuscate the source code if you wish, but if you are releasing in Release build mode, and you are not providing the .PDB, then this is the first step.

Ultimately, the DLL / EXE can be decompiled anyway, so its up to you. Debug mode will reveal a lot more than Release mode, but not much more.

Dominic Zukiewicz
  • 8,258
  • 8
  • 43
  • 61
2

Released application should not crash when exception occurs. You will want to inform the user, something went wrong and log your exception, but you do not want to crash! Informing user should be done in a friendly manner and not just by putting exception.ToString() into the message box.

It is a good practice to add Application.ThreadException or AppDomain.CurrentDomain.UnhandledException handlers to handle all exceptions in your Application. How exactly to do that, is answered in the following thread: Catch Application Exceptions in a Windows Forms Application However, make sure that your application survives in a usable state, i.e. handle exceptions in a proper way for your application.

I usually add a preprocessor directive for handling exceptions on the application level, since I want them to trow while debugging. For example:

#if !DEBUG 
   Application.ThreadException += new ThreadExceptionEventHandler(MyHandler);
#endif

It should also be mentioned, that if you have code pieces where you anticipate that Exception might occur, such as network communication error, you should handle those pieces explicitly. What I am saying is, we should not completely forget about exception handling, just because we configured an unhandled exception handler on the application level.

Community
  • 1
  • 1
Edin
  • 1,476
  • 11
  • 21
0

Ideally, you should be catching anything that's thrown higher with throw;. Carefully check your code and try to ensure that thrown exceptions are dealt with appropriately. Unhandled exceptions are logged - you can see this information in the Windows Event Viewer. Depending on what details you put in them, unhandled exceptions could give clues as to the inner workings of your application. However, I would suggest that unhandled exceptions are a poor source of information, and that anyone who wanted to know how your application worked could simply disassemble it, unless you've obfuscated it.

Some exceptions cannot be caught by surrounding code with try/catch blocks, so your application should also implement an unhandled exception handler. This gives you the opportunity to show the user an error message and do something with the exception - log it, send it to support, discard it, etc.

Chris Mantle
  • 6,595
  • 3
  • 34
  • 48