Automatic insertion of try catch block

[fjdiewornncalwe]

You may wish to ask yourself why you want to insert a try-catch into every method you are creating. That is no way to trap errors properly. It will just make the entire application nearly impossible to effectively debug the application. If you do wish to do it, look up on how to creating studio add-ins. You may want to tie in that way to automate the process with no user intervention(i.e. keystrokes), but the logical way would be to create a snippet, and assign a keystroke to it so that you only have to type that to get the whole block inserted.

I wasn't, now I am, then I won't be anymore.

[OriginalGriff]

I'm with PogoboyKramer on this - try catch round each and every method just look like you are saying "I don't know what I am doing, so I'll try and ignore as many problems as I can instead of fixing the problems behind them" Smacks to me of VB's "On Error Resume Next" X|

Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.

[fjdiewornncalwe]

OriginalGriff wrote:

On Error Resume Next

Goto Happyland

I wasn't, now I am, then I won't be anymore.

[OriginalGriff]

PogoboyKramer wrote:

Goto VeryUnHappyland if you are the poor sod maintaining it...

FTFY! :laugh:

Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.

[fjdiewornncalwe]

Reading between the lines... You've worked with BA's before

I wasn't, now I am, then I won't be anymore.

[OriginalGriff]

Who hasn't? :laugh:

Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.

[Dave Kreskowiak]

If you like removing said Try/Catch blocks all the time, this would be a good idea. But, it's a horrible idea to put a try/catch block in every method. You're not really doing/handling exceptions properly if this is the case, but instead making a nightmare of debugging your app.

A guide to posting questions on CodeProject[^]
Dave Kreskowiak

[thomforum]

Dave -- Tell me one instance where you wouldn't prefer placing a try/catch in a method. cheers

[jschell]

thomforum wrote:

Tell me one instance where you wouldn't prefer placing a try/catch in a method.

Two instances. There are many others.

public int Count
{
get { return count; }
set
{
if (value >= 0)
count = value;
}
}
private int count;

public void Initialize(String name)
{
if (String.IsNullOrEmpty(name))
throw new ArgumentException("Name must be defined");
this.name = name;
}

I also do not want to see the following. The following might require try/catch somewhere but logging the exception twice does nothing but provide confusion. So the question becomes what does the one try/catch do that the other does not?

private void ProcessTxn()
{
try
{
...
}
catch(Exception e)
{
__log.Error("Failed to process txn", e);
throw;
}
}

public void Process()
{
try
{
PrepareTxn();
ProcessTxn();
SaveTxn();
}
catch(Exception e)
{
__log.Error("Failed to process", e);
throw;
}
}

[fjdiewornncalwe]

I think the discussion isn't about the inherent value of a try-catch block. It is the problems associated with simply making an exception go away with no logging or anything in an empty try catch.

I wasn't, now I am, then I won't be anymore.

[Lost User]

You'd want to handle the ThreadException[^]. If you want to swallow exceptions, do it there - after logging them or something like that. There's an example on the page on setting up basic exception-handling.

I are Troll :suss:

[Pete OHanlon]

You should only use a try/catch if you plan to do something with the exception. Exception handling is intended to provide a defense mechanism, where you can actually handle the exception - what's the point of just consuming it? If you just catch the exception then you don't know that part of your code encountered a problem, so you end up masking problems from a user. As an example, what happens if you have a network connection open and connectivity is lost? If you are writing to the network stream, it's a good idea to know that it's closed unexpectedly during a stream write, so you can inform the user that the write didn't complete successfully.

thomforum wrote:

Tell me one instance where you wouldn't prefer placing a try/catch in a method.

This, effectively, is blind optimism. Use exception handling for what it's intended for.

I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Onyx

[Dave Kreskowiak]

When I want the exception to bubble up to a higher level to be handled at a business process level where I can centralize problem logging and abort whatever transaction is going on at the time, which is most of the time. Doing it your way would limit the exception to that function, where you'd have to throw a new exception to get it to go higher. But, don't take my word for it. There's tons of articles on the subject: Google Results[^]

A guide to posting questions on CodeProject[^]
Dave Kreskowiak

[RaviBee]

Yes. See this[^] code snippet. /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

[abinmaths]

to add try catch block u type try and give two tab entry using key board u will get the try catch block automaticly