try-catch code convention [modified]

[Jammer 0]

I think the point was that it was in EVERY method ...

Jammer My Blog | Articles | DMon | SampleSort

[_beauw_]

Originally I think that was the point. The post I actually responded to seemed to impugn any and all squelching of exceptions ("[s]adly enough, I used to swallow exceptions in code as well..."). This blanket statement is actually one I hear a lot, even from people pretty well-placed in software development.

[DaveyM69]

Jon Sagara wrote:

Try/Swallow

I'm scared to reply to that one!

Dave

If this helped, please vote & accept answer!

Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum.(Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)

[_beauw_]

I think it's true that failures related to some less significant features should not be allowed to disrupt other features. Even logging these failures in a production environment can impact other critical systems. So, there are probably legitimate cases where errors related to an entire subsystem should be squelched in the production build. Doing this is, at some level, a revival of ON ERROR RESUME NEXT. At a minimum, I think that good programming practices dictate that unhandled exceptions should halt the program in its development builds (even if some of these are squelched in the "release" build). So long as the transition between build modes is automatic and reliable, this can be a good approach to exception handling for some applications.

[Kunal Chowdhury IN]

try{} catch{} blocks should be use only when you need it. Else there will be a performance issue. It is not recommended to write try catch block for the whole code of any method. Where you expect to be a codeflaw, where exception may come just put your try catch there. Don't try to use generic exception in all the case. If you know some specific exception that may come, only catch those explicitly.

Don't forget to Click on [Vote] and [Good Answer] on the posts that helped you.

---

Regards - Kunal Chowdhury | Software Developer | Chennai | India | My Blog | My Tweets | Silverlight Tutorial

[fjdiewornncalwe]

What you don't see, can't hurt you... It'll only hurt the guy who has to fix it.

[Lost User]

_beauw_ wrote:

Even logging these failures in a production environment can impact other critical systems.

..logging doesn't require much resources (a small ringbuffer?), and should not influence the working of dependent systems. Having a global error handler that logs anything that's not expected helps a lot when maintaining the application.

I are Troll :suss:

[Yusuf]

DaveyM69 wrote:

Jon Sagara wrote: Try/Swallow I'm scared to reply to that one! Dave

Promise, it won't swallow you, Dave. ;P

Yusuf May I help you?

[Stephen Hewitt]

Eddy Vluggen wrote:

you'll be the source of all bugs and errors if you try to move to structured error-handling Smile

Fair point.

Steve

[Abhinav S]

Kevin Drzycimski wrote:

they are world market leader

Whatever sells! :sigh:

The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.

[Kevin Drzycimski]

Eddy Vluggen wrote:

you'll be the source of all bugs and errors if you try to move to structured error-handling

so right^^ once turning on printing error messages to stderr, there was so much outpu - it was turned off immediately :laugh:

[_beauw_]

If you mean to say that every exception should be logged in every piece of software, or even in every .NET application, I just cannot endorse that view. Logging is I/O, which is a failure-prone and time-consuming category of operation. Consider what happens if I attempt to log inside of a deeply nested loop; some very bad things could happen, if the loop needs to continue executing on a real-time basis. In the "debug" build, everything can grind to a halt... in production, the time for that is over. Again, this is not necessarily a far-fetched scenario. There are .NET applications that control, or at least influence, real-time machinery. There are .NET programs that guide stock traders in real-time. Entering into an I/O routine is not always an acceptable response to failure in such environments, no matter how nice it sounds at the Airport Sheraton.

modified on Wednesday, July 14, 2010 7:43 PM

[Lost User]

_beauw_ wrote:

Logging is I/O, which is a failure-prone and time-consuming category of operation.Consider what happens if I attempt to log inside of a deeply nested loop;

I wouldn't expect a lot of unexpected exceptions in a deeply-nested loop.

_beauw_ wrote:

There are .NET applications that control, or at least influence, real-time machinery.

.NET isn't recommended for time-critical operations, but how many exceptions could the app raise per 50ms?

_beauw_ wrote:

There are .NET programs that guide stock traders in real-time. Entering into an I/O routine is not always an acceptable response to failure in such environments

I'm not talking about logging those exceptions that you handle locally, but those that you didn't expect and that don't get handled. There shouldn't be too many of those, and you wouldn't want to swallow those. Wouldn't want to ignore an divide by zero and price those stocks at "no worth" :)

I are Troll :suss:

[Alois Kraus]

Sounds familar :) Perhaps you should add at least some tracing to your methods like this one Then your code would be transparent to exceptions but you can still see what exceptions did flow through your code without becoming much slower.

    public void Demo\_Show\_Leaving\_Trace\_With\_Exception()
    {
        TracerConfig.Reset("console");
        SomeMethod();
    }

    void SomeMethod()
    {
        using (Tracer t = new Tracer(myType, "SomeMethod"))
        {
            SomeOtherMethod();
        }
    }

    private void SomeOtherMethod()
    {
        using (Tracer t = new Tracer(myType, "SomeOtherMethod"))
        {
            FaultyMethod();
        }
    }

    private void FaultyMethod()
    {
        throw new NotImplementedException("Hi this a fault");
    }

The output would look the like this: 18:57:46.665 03064/05180 <{{ > ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeMethod 18:57:46.668 03064/05180 <{{ > ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeOtherMethod 18:57:46.670 03064/05180 < }}< ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeOtherMethod Exception thrown: System.NotImplementedException: Hi this a fault at ApiChange.IntegrationTests.Diagnostics.TracingTests.FaultyMethod() at ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeOtherMethod() at ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeMethod() at ApiChange.IntegrationTests.Diagnostics.TracingTests.Demo_Show_Leaving_Trace_With_Exception() 18:57:46.670 03064/05180 < }}< ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeOtherMethod Duration 2ms 18:57:46.689 03064/05180 < }}< ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeMethod Duration 24ms That is a great time saver to find out where some exception did come from without the need to type try/catch(Exception ex) { LogException(ex);throw; } in many methods to find out where some exception did go through. Yours, Alois Kraus

[whatrevolution]

Try/Swallow is an affective form of birth control.

Honestly Illustrated

<Pretentious> Raid tha manyuhl. :E <Pretentious> Aw raid eh own mah meaxbile. :E

[Hired Mind]

They've implemented the most efficient source of Mystery Errors ever devised.

Before .NET 4.0, object Universe = NULL;