Automatic insertion of try catch block

[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