By default an unhandled exception in any application will kill an application and return an exception trace even in a windows form.

In Delphi in a forms application the exception shows as a message box.

The assumption in Visual C++ and then C# is that an unhandled exception could result in data corruption so you must shut down now. The assumption in delphi is that some error has occoured.

It is possible to add simple code to emulate the Delphi behavior

// Add the following to your uses clause:
using System.Threading;

//In your main method before run implement the following

Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(new CustomExceptionHandler().OnThreadException);

// Here is the exception handler (in production code use something more elegant, but for development this is fine:

        // Creates a class to handle the exception event.
        internal class CustomExceptionHandler
        {
 
            //Handles the exception event
            public void OnThreadException(object sender, ThreadExceptionEventArgs t)
            {
                DialogResult result = DialogResult.Cancel;
                try
                {
                    result = this.ShowThreadExceptionDialog(t.Exception);
                }
                catch
                {
                    try
                    {
                        MessageBox.Show(“Fatal Error”, “Fatal Error”,
                            MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop);
                    }
                    finally
                    {
                        Application.Exit();
                    }
                }
 
                // Exits the program when the user clicks Abort.
                if (result == DialogResult.Abort)
                    Application.Exit();
            }
 
            // Creates the error message and display it.
            private DialogResult ShowThreadExceptionDialog(Exception e)
            {
                string errorMsg = “An error occurred please contact the adminstrator ” +
                    “with the following information: “;
                errorMsg = errorMsg + e.Message + ” Stack Trace: ” + e.StackTrace;
                return MessageBox.Show(errorMsg, “Application Error”,
                    MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop);
            }
        }

    }

However this should be the default behaviour.

TFoo = class(TObject);

TFooClass = class of TFoo;

function MakeFoo( aFooClass : TFooClass ) : TFoo;
begin
    result := aFooClass.Create();
end;

This allows very generic code where you can get away with just passing in a class name.
I use this heavily in Delphi as part of a test framework (the meta class represents test data).

I think that this can be done in C# using reflection but there should be a cleaner method.

C () : base () { }

It is possible to have more code in the base () parameters than in the implementation itself.

You need to redefine any constructors that are required in a descendant class.
This makes the definition of mostly empty classes such as exception hireachies far more work than is actually needed.

Delphi has trivial to implement Exceptions :

type
   EBaseException = class(Exception);

  EMyException = class(EBaseException);

This makes their definition and use so useful.

I am wondering if it is possible to create an Exception Definition Language to ease this issue?
I will Blog about this experiment later.

In Delphi you can declare an enumeration as

TEnumColour = (Red, Green, Blue);

You can then declare an array over that enumeration:

TWaveLength : array[TEnumColour] of integer  = (100,200,300);

This is a very powerful technique for ensuring that an enumeration always has valid data.

I have yet to work out how to do this in C#