Custom Exceptions

M

mooman_fl

Centurion
Joined
Nov 3, 2002
Messages
193
Location
Florida, USA
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.
 
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.
 
Last edited:
You could just display the message from the exception and then rethrow the exception.
C#: 
try
{
	// something that will throw an exception
}
catch (Exception ex)
{
	MessageBox.Show(ex.Message);
	throw ex;
}
An unhandled exception should terminate the program.
 
And if you want to use the try catch method

Visual Basic: 
Try

catch ex as exception

finally
' Processes next step after handling the error
end try
 
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.
 
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.
 
here is a way in VB. Not sure what you are lookng for
Visual Basic: 
On Error Goto ErrorHandle
'code here
exit sub
ErrorHandle:
messagebox.show("BLABLAH")
Resume Next
 
Well, that's still not going to do it. In VB it is pretty much the same:
Visual Basic: 
        Try

            ' do something that might throw an exception

        Catch ex As Exception

            messagebox.show(ex.Message)

            Throw ex

        End Try
 
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:

  1. At least the common exceptions like that don't shut down the program as they used to even if uncaught.
  2. Even injecting your custom message will result in a very unprofessional looking exception dialog.
  3. 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
 
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.
 
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.
 
Last edited:
Back
Top