mooman_fl Posted October 6, 2006 Posted October 6, 2006 I already know how to throw an exception with a custom message. I also know how to try/catch exceptions. What I need is a little different. I need to be able to catch an exception ONLY to pass a message to the user via a messagebox then let the normal handling of the exception continue (i.e. shutting down the program). I don't want to have to shut down the program programmatically. Is this possible? I have a sneaking suspicion it might involve subclassing the System.Exception class to make a custom exception routine. Hoping there might be a slightly easier way. Quote "Programmers are tools for converting caffeine into code." Madcow Inventions -- Software for the Sanity Challenged.
Administrators PlausiblyDamp Posted October 6, 2006 Administrators Posted October 6, 2006 (edited) Exceptions aren't designed to be used in this way - they are a way to signal an error not just as a means of passing a message. You probably want to look at using / raising events as they would be far more suitable in this scenario. Alternatively you might want to look at handling the AppDomain.CurrentDomain.UnhandledException event. Edited October 6, 2006 by PlausiblyDamp Quote Posting Guidelines FAQ Post Formatting Intellectuals solve problems; geniuses prevent them. -- Albert Einstein
Gill Bates Posted October 6, 2006 Posted October 6, 2006 You could just display the message from the exception and then rethrow the exception.try { // something that will throw an exception } catch (Exception ex) { MessageBox.Show(ex.Message); throw ex; }An unhandled exception should terminate the program. Quote
techmanbd Posted October 6, 2006 Posted October 6, 2006 And if you want to use the try catch method Try catch ex as exception finally ' Processes next step after handling the error end try Quote Live as if you were to die tomorrow. Learn as if you were to live forever. Gandhi
Gill Bates Posted October 6, 2006 Posted October 6, 2006 Adding the finally block will not help any since the Exception will be out of scope. He needs to display the exception message and then let the exception flow continue. Quote
techmanbd Posted October 6, 2006 Posted October 6, 2006 Oh ok, I went back and read what he was looking for a third time. I see hwta he is looing for now. Sorry, brain is a little fried. Been working on this project trying to get something to work for thepast 2 days. Quote Live as if you were to die tomorrow. Learn as if you were to live forever. Gandhi
techmanbd Posted October 6, 2006 Posted October 6, 2006 here is a way in VB. Not sure what you are lookng for On Error Goto ErrorHandle 'code here exit sub ErrorHandle: messagebox.show("BLABLAH") Resume Next Quote Live as if you were to die tomorrow. Learn as if you were to live forever. Gandhi
Gill Bates Posted October 6, 2006 Posted October 6, 2006 Well, that's still not going to do it. In VB it is pretty much the same: Try ' do something that might throw an exception Catch ex As Exception messagebox.show(ex.Message) Throw ex End Try Quote
mooman_fl Posted October 6, 2006 Author Posted October 6, 2006 Thanks PlausiblyDamp and all that have answered. I supposed I better get a little more general AND a little more specific, and explain what I am wanting to do and why. What I was trying to do is find a way that I can shut down a program without having to use the standard programmatic methods for reasons of obfuscation. Just throwing an exception of course will not do it, and I have come to realize that. My concern is disassembly of my product... it would be easy to search in MSIL code or even reconstituted VB/C# .Net for the standard methods of shutting down programmatically, and then remove them. My thought, although erroneous, was using an error (i.e. a sneaky divide-by-zero) to cause an exception, pass my custom message saying they didn't have the right registration info, then let the exception shut it down. One of the things I realized though in testing after I posted, was that: At least the common exceptions like that don't shut down the program as they used to even if uncaught. Even injecting your custom message will result in a very unprofessional looking exception dialog. It just plain isn't going to work. That being said, I would be open to any suggestions that might accomplish the goal of shutting down the program or DLL assembly without easily traced and removed code. Personally though I am beginning to think that this is going to be just an instance of "nothing you can really do". Seems that intellectual property security is not a big advantage and actually more of a liability with .NET Quote "Programmers are tools for converting caffeine into code." Madcow Inventions -- Software for the Sanity Challenged.
Gill Bates Posted October 6, 2006 Posted October 6, 2006 The bottom line is that if somebody wants to break your licensing algorithm -- they will, even if your application is written in C or straight Assembly. Granted, with a managed platform like .NET, decompiling the assembly is vastly easier. There are tools available to obfuscate your assemblies. Check out this article: http://www.yoda.arachsys.com/csharp/obfuscation.html I basically agree with everything that is said there. Quote
mooman_fl Posted October 6, 2006 Author Posted October 6, 2006 (edited) Hadn't read that article before, but read a few like it. I agree also. I wasn't attempting to make a foolproof program, just a more difficult one. Just because it isn't easy to obfuscate your methods in .NET doesn't mean you need to serve it on a silver platter. :p All in all, I am not worried about most people getting ahold of my code. But I just don't want to make it easy on them to do so. If I can make them lose more than two hairs in frustration when they try, I feel I have accomplished my purpose. ;) The assembly isn't going to be world shattering, just extremely useful to project developers. It is a plugin manager control. Drop it on your form, set a few properties, like plugin directory, and interface libraries, and it will load your plugins AND provide a plugin manager control that you can add to your program. You will be able to have managed and unmanaged plugins. That simply means that plugins that use the built in IPlugInfo interface will be managed, those that don't won't be managed by the manager. Managed plugins can have startup properties set (start at runtime, etc) so the end user of the program can decide which ones they want running. Unmanaged plugins will always run at runtime and don't show in the manager at all, so that is good for core application code. The overall goal is to provide a reusuable control that will make plugins a simple operation for the developer. Edited October 6, 2006 by mooman_fl Quote "Programmers are tools for converting caffeine into code." Madcow Inventions -- Software for the Sanity Challenged.
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.