C#: Try-catch every line of code without individual try-catch blocks?

It's pretty obvious that you'd write the code in VB. NET, which actually does have On Error Resume Next and export it in a DLL to C#. Anything else is just being a glutton for punishment.

It's pretty obvious that you'd write the code in VB. NET, which actually does have On Error Resume Next, and export it in a DLL to C#. Anything else is just being a glutton for punishment.

I do believe that this is a valid solution which solves the puzzle posed in the question, so I am accepting the answer! – tags2k Sep 24 '08 at 7:35.

Public delegate void VoidDelegate(); public static class Utils { public static void Try(VoidDelegate v) { try { v(); } catch {} } } Utils. Try( () => WidgetMaker. SetAlignment(57) ); Utils.

Try( () => contactForm"Title" = txtTitle. Text ); Utils. Try( () => Casserole.

Season(true, false) ); Utils. Try( () => ((RecordKeeper)Session"CasseroleTracker"). Seasoned = true ).

This makes the most sense, really. – Jon Limjap Sep 23 '08 at 2:18 6 As of . Net 3.5, you can use Action instead of voidDelegate.

– David B Sep 23 '08 at 15:04 I love this! This is like getting the @ operator from PHP in C#. Php.Net/manual/en/language.operators.errorcontrol.

Php And I don't have to write this question. – brunot Jan 16 '09 at 20:36 How come Action works here also even if you start passing parameters? Is the compiler handling this for you... like ignoring or dropping the params?

– brunot Jan 16 '09 at 21:31 3 The major problem here is the "catch {}" which will catch things that should never be caught, including low-level errors in the state of the CLR. – Daniel Earwicker Mar 23 '09 at 8:46.

Refactor into individual, well-named methods: AdjustFormWidgets(); SetContactTitle(txtTitle. Text); SeasonCasserole(); Each of those is protected appropriately.

I would say do nothing. Yup thats right, do NOTHING. You have clearly identified two things to me: You know the architecture is borked.

There is a ton of this crap. I say: Do nothing. Add a global error handler to send you an email every time it goes boom.

Wait until something falls over (or fails a test) Correct that (Refactoring as necessary within the scope of the page). Repeat every time a problem occurs. You will have this cleared up in no time if it is that bad.

Yeah I know it sounds sucky and you may be pulling your hair out with bugfixes to begin with, but it will allow you to fix the needy/buggy code before the (large) amount of code that may actually be working no matter how crappy it looks. Once you start winning the war, you will have a better handle on the code (due to all your refactoring) you will have a better idea for a winning design for it.. Trying to wrap all of it in bubble wrap is probably going to take just a long to do and you will still not be any closer to fixing the problems.

My exact method on umpteen projects - great explanation – zanlok Jun 25 at 23:47.

Fail Fast To elaborate, I guess I am questioning the question. If an exception is thrown, why would you want your code to simply continue as if nothing has happened? Either you expect exceptions in certain situations, in which case you write a try-catch block around that code and handle them, or there is an unexpected error, in which case you should prefer your application to abort, or retry, or fail.

Not carry on like a wounded zombie moaning 'brains'.

This is one of the things that having a preprocessor is useful for. You could define a macro that swallows exceptions, then with a quick script add that macro to all lines. So, if this were C++, you could do something like this: #define ATTEMPT(x) try { x; } catch (...) { } // ... ATTEMPT(WidgetMaker.

SetAlignment(57)); ATTEMPT(contactForm"Title" = txtTitle. Text); ATTEMPT(Casserole. Season(true, false)); ATTEMPT(((RecordKeeper)Session"CasseroleTracker").

Seasoned = true); Unfortunately, not many languages seem to include a preprocessor like C/C++ did. You could create your own preprocessor and add it as a pre-build step. If you felt like completely automating it you could probably write a preprocessor that would take the actual code file and add the try/catch stuff in on its own (so you don't have to add those ATTEMPT() blocks to the code manually).

Making sure it only modified the lines it's supposed to could be difficult though (have to skip variable declarations, loop constructs, etc to that you don't break the build). However, I think these are horrible ideas and should never be done, but the question was asked. :) Really, you shouldn't ever do this.

You need to find what's causing the error and fix it. Swallowing/ignoring errors is a bad thing to do, so I think the correct answer here is "Fix the bug, don't ignore it! ".

:).

1 someone who actually answers the question, you got my vote ;) – mattlant Sep 22 '08 at 20:09 1 The problem is this still wouldn't work as intended, at least not without some additional thinking. If you do this then it's almost garunteed you're going to move variables out of scope and break your build. – Orion Adrian Sep 22 '08 at 20:12 That's why I said you need to be careful to skip variable declarations, along with other things.

– Herms Sep 22 '08 at 20:16 1 Even if you don't break your build, which would be hard, there's a ton of stuff to actually look for beyond just variable declarations and looping constructs. I know you're suggesting he actually go through with it (quite the contrary). – Orion Adrian Sep 22 '08 at 20:21 But that's just what makes trying to write a tool for this fun!(or incredibly painful).

:) – Herms Sep 22 '087 at 13:49.

On Error Resume Next is a really bad idea in the C# world. Nor would adding the equivalent to On Error Resume Next actually help you. All it would do is leave you in a bad state which could cause more subtle errors, data loss and possibly data corruption.

But to give the questioner his due, you could add a global handler and check the TargetSite to see which method borked. Then you could at least know what line it borked on. The next part would be to try and figure out how to set the "next statement" the same way the debugger does it.

Hopefully your stack won't have unwound at this point or you can re-create it, but it's certainly worth a shot. However, given this approach the code would have to run in Debug mode every time so that you would have your debug symbols included.

Rewrite the code. Try to find sets of statements which logically depend on each other, so that if one fails then the next ones make no sense, and hive them off into their own functions and put try-catches round them, if you want to ignore the result of that and continue.

As someone mentioned, VB allows this. How about doing it the same way in C#? Enter trusty reflector: This: Sub Main() On Error Resume Next Dim I As Integer = 0 Dim y As Integer = CInt(5 / i) End Sub Translates into this: public static void Main() { // This item is obfuscated and can not be translated.Int VB$ResumeTarget; try { int VB$CurrentStatement; Label_0001: ProjectData.

ClearProjectError(); int VB$ActiveHandler = -2; Label_0009: VB$CurrentStatement = 2; int I = 0; Label_000E: VB$CurrentStatement = 3; int y = (int) Math. Round((double) (5.0 / ((double) i))); goto Label_008F; Label_0029: VB$ResumeTarget = 0; switch ((VB$ResumeTarget + 1)) { case 1: goto Label_0001; case 2: goto Label_0009; case 3: goto Label_000E; case 4: goto Label_008F; default: goto Label_0084; } Label_0049: VB$ResumeTarget = VB$CurrentStatement; switch (((VB$ActiveHandler > -2)? VB$ActiveHandler : 1)) { case 0: goto Label_0084; case 1: goto Label_0029; } } catch (object obj1) when (?) { ProjectData.

SetProjectError((Exception) obj1); goto Label_0049; } Label_0084: throw ProjectData. CreateProjectError(-2146828237); Label_008F: if (VB$ResumeTarget! = 0) { ProjectData.

ClearProjectError(); } }.

Very funny :):) Given the very nature of this question, I would recommend the original poster to implement this approach as soon as he faces the problem - it is the closest to his question. It is the same as the accepted answer (do it in VB and use on error resume next) and it is in C#. And I would also recommend him to face the rage of someone having to maintain this after him.It is about the mindset...you either want to try-catch every line of a thousand lines long method, or you refactor that method and make the whole thing better.

No what-if thought experimeents needed. – Marek Dec 22 '09 at 22:43 @Marek, refactoring is a great objective, however there are times that you have to keep the whole mess running while you overhaul it. Users hate it when they lose data because of an unhandled exception closes the application.

They don't point to the fool who wrote made the mess, but at the developer now responsible. – Andrew Neely Aug 3 at 15:08.

You could use goto, but it's still messy. I've actually wanted a sort of single statement try-catch for a while. It would be helpful in certain cases, like adding logging code or something that you don't want to interrupt the main program flow if it fails.

I suspect something could be done with some of the features associated with linq, but don't really have time to look into it at the moment. If you could just find a way to wrap a statement as an anonymous function, then use another one to call that within a try-catch block it would work... but not sure if that's possible just yet.

If you can get the compiler to give you an expression tree for this code, then you could modify that expression tree by replacing each statement with a new try-catch block that wraps the original statement. This isn't as far-fetched as it sounds; for LINQ, C# acquired the ability to capture lambda expressions as expression trees that can be manipulated in user code at runtime. This approach is not possible today with .

NET 3.5 -- if for no other reason than the lack of a "try" statement in System.Linq.Expressions. However, it may very well be viable in a future version of C# once the merge of the DLR and LINQ expression trees is complete.

This may help you in identifing the pieces that have the most problems. @ JB King Thanks for reminding me. The Logging application block has a Instrumentation Event that can be used to trace events, you can find more info on the MS Enterprise library docs.

Using (New InstEvent) End Using All of the steps in this using will be traced to a log file, and you can parse that out to see where the log breaks (ex is thrown) and id the high offenders. Refactoring is really your best bet, but if you have a lot, this may help you pinpoint the worst offenders.

You could create a class that reflects on the code and use line #s as the hint for what to put in each individual try/catch block. This has a few advantages: Its slightly less ugly as it doesn't really you require mangle your source code and you can use it only during debug modes. You learn something interesting about c# while implementing it.

I however would recommend against any of this, unless of course you are taking over maintance of someelses work and you need to get a handle on the exceptions so you can fix them. Might be fun to write though.

Fun is always good. Glad to see some more people's insite into this. – mattlant Sep 23 '08 at 2:26.

Fun question; very terrible. It'd be nice if you could use a macro. But this is blasted C#, so you might solve it with some preprocessor work or some external tool to wrap your lines in individual try-catch blocks.

Not sure if you meant you didn't want to manually wrap them or that you wanted to avoid try-catch entirely. Messing around with this, I tried labeling every line and jumping back from a single catch, without much luck. However, Christopher uncovered the correct way to do this.

There's some interesting additional discussion of this at Dot Net Thoughts and at Mike Stall's . NET Blog. EDIT: Of course.

The try-catch / switch-goto solution listed won't actually compile since the try labels are out-of-scope in catch. Anyone know what's missing to make something like this compile? You could automate this with a compiler preprocess step or maybe hack up Mike Stall's Inline IL tool to inject some error-ignorance.(Orion Adrian's answer about examining the Exception and trying to set the next instruction is interesting too.) All in all, it seems like an interesting and instructive exercise.

Of course, you'd have to decide at what point the effort to simulate ON ERROR RESUME NEXT outweighs the effort to fix the code. :-).

Unfortunately you are probably out of luck. On Error Resume Next is a legacy option that is generally heavily discouraged, and does not have an equivalent to my knowledge in C#. I would recommend leaving the code in VB (It sounds like that was the source, given your specific request for OnError ResumeNext) and interfacing with or from a C# dll or exe that implements whatever new code you need.

Then preform refactoring to cause the code to be safe, and convert this safe code to C# as you do this.

You could look at integrating the Enterprise Library's Exception Handling component for one idea of how to handle unhandled exceptions. If this is for ASP. Net applications, there is a function in the Global.

Asax called, "Application_Error" that gets called in most cases with catastrophic failure being the other case usually.

Ignoring all the reasons you'd want to avoid doing this....... If it were simply a need to keep # of lines down, you could try something like: int totalMethodCount = xxx; for(int counter = 0; counter Season(true, false); if (counter == 3) ((RecordKeeper)Session"CasseroleTracker"). Seasoned = true; } catch (Exception ex) { // log here } } However, you'd have to keep an eye on variable scope if you try to reuse any of the results of the calls.

Very creative.. – zanlok Jun 25 at 23:50 I would rather slap the person who would implement this in the face and let myself fired from the job than having to maintain this – Marek Aug 4 at 11:28.

Catch the errors in the UnhandledExecption Event of the application. That way, unhandled execptions can even be logged as to the sender and whatever other information the developer would reasonable.

One at a time, 'Surround with' try/catch. That avoids the copying pasting you mentioned.

This doesn't actually work. You'll break scoping. Int i; I = 5; can't be try catch'ed.

– Orion Adrian Sep 22 '08 at 20:17 What the hell are you talking about? Where in the heck was there any variable assignment in the posters question? – mattlant Sep 22 '08 at 20:29 The implication was that it was "times 100" meaning that there's a lot of code there that wasn't presented.In that case then there's bound to be a variable assignment or two along with the dozen or so other constructs that can't be try/catch'ed singly.

– Orion Adrian Sep 22 '08 at 20:33 100 X those four lines of code still presents ZERO assignments. – mattlant Sep 22 '08 at 20:34 1 @mattlant I would give you +1 for funniest answer in this thread, but I am afraid that you are being serious :):):) – Marek Sep 22 '087 at 22:47.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.