I miss Visual Basic's "On Error Resume Next" in C#. How should I be handing errors now?

Question

In Visual Basic I wrote just On Error Resume Next in the head of my program and errors were suppressed in the entire project.

Here in C# I miss this feature very much. The usual try-catch handling for every single procedure is not only very time-intensive, it brings undesired effects. If an error is encountered, even if handled, the code doesn't continue from the point it occurred. With On Error Resume Next, the code continued from the point of error, skipping just the function call that caused the error.

I am not deeply involved with C# yet, but maybe there exists in C# a better error handling than the primitive try-catch.

I also would like to have the module or function name where the error occured as well as the the line number in my error message. The Exception class doesn't provide that features as far I know. Any ideas (managed, of course, without involving any process classes on my own application)?

How do you handle the errors in bigger projects? I hope I do not have to add a try-catch to each method. Somehow C# throws many errors - that seems to be typical of the language.

My Solution which I found to re-solve several of my problems:

public partial class Form1 : Form
{

    public Form1()
    {
        InitializeComponent();
    }

    [STAThread]
    static void Main()
    {
      Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException); //setup global error handler
      Application.Run(new Form1());
    }

    private static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
    {   
            MessageBox.Show("Unhandled exception: " + e.Exception.ToString()); //get all error information with line and procedure call
            Environment.Exit(e.Exception.GetHashCode()); //return the error number to the system and exit the application
    }

    private void button1_Click(object sender, EventArgs e)
    {
        string s = ""; s.Substring(1, 5); //Produce an error
    }

   }

Answer 1

Continuing after errors as if nothing's happened is a terrible way of programming.

Can't work out the new balance of the account? That's okay, let's just store it as 0. No-one will ever know, right?

try/catch blocks should actually be relatively rare, because there are relatively few errors you can really recover from. Typically you should have one try/catch block at the top of some logical operation, so that if it fails you can inform the user and continue with other entirely separate operations - or terminate the app completely, depending on the kind of application you're writing. (Web apps are a good example here: you can fail the request, hopefully taking care that you don't have nasty persistent side-effects, and continue to handle other requests.)

Where there are places you legitimately expect errors you can recover from, catch those specific exceptions and handle them appropriately (e.g. falling back to writing to a file if writing to a database fails). Again, these are relatively few and far between. If you find yourself writing a try/catch block in every method (or even every class) then you're probably handling exceptions inappropriately.

I also would like to have the module or function name where the error occured as well the line number in my error message. The Exception class doesn't provide that features as far I experienced.

Yes it does. The stack trace shows the type, method and line number (where available) for each frame in the stack... as well as a (hopefully useful) message, of course. Oh, and potentially a nested exception too, if one failure was caused by another.

Somehow C# throws many errors on execution always, that's language typical.

Nope, that just suggests you're Doing It Wrong.