Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / January 2008

Tip: Looking for answers? Try searching our database.

Resume Exception After Handling Exception in C#

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
beginner - 14 Jan 2008 18:29 GMT
Hello,

We are writing a performance critical application. As a result, we use
Array instead of List or any other more sophisticated container types
to store temporary data. However, the array type is of fixed length,
and therefore there is a chance for the index to be out of range. I
expect this to happen once every a hundred times of execution and when
this happens, I'd like to create a bigger array. To prevent the bounds
from being checked every time, I am thinking of the following code (in
sketch):

int [] l= new int[100]; .//temp variable
....
try
{

 int count=0;
  while(...)
  {
    ...
     l[count++]=f(...);   //
    ....
    l[count*2+1]=f(...); //multiple places that put stuff into the
array
  }

}
catch(OutOfRange e)
{
   //create a bigger array
   l2=new int[count*2+100];
   //copy partial results from old array to new array
   ...
  //replace old array
   l=l2
   resume execution right after the exception was thrown
}

But I don't think there is a way in C# to support this pattern.

I think this is a really useful pattern, as it is way more efficient
to deal with such conditions that happen once in a million times.

Thanks,
Geoffrey
Marc Gravell - 14 Jan 2008 18:37 GMT
> But I don't think there is a way in C# to support this pattern.
Correct; there is no resume

> I think this is a really useful pattern, as it is way more efficient
> to deal with such conditions that happen once in a million times.

Are you so sure? Have you times it both ways? Since the base-libraries
use mainly bounds-checking, I'm guessing that it isn't as slow as you
think. Of course, exceptions aren't as slow as people think, either...
Of course, the cheapest option is to check your length ahead of time
(outside of any loop).

Marc
beginner - 14 Jan 2008 19:48 GMT
> > But I don't think there is a way in C# to support this pattern.
>
[quoted text clipped - 10 lines]
>
> Marc

Unfortunately checking the Length beforehand is impossible as I only
know the ballpark of the number of records I have to process and there
could be big outliers.

You are probably right. In this case, I might be able to banking on
the smartness of the optimizer. If I check the bounds explicitly in
the code, the JIT might not generate code that implicitly does so and
throws exceptions.

But this is still a useful pattern in dealing with things like
numerical computations, which is another situation I am trying to use
this pattern. It is cheaper to handle rare bad situations when it
actually happens. Without the 'resume' mechanism, I will have to redo
the whole function when some exception happens. With the resume, I can
redo at much finer granuality.
Nicholas Paldino [.NET/C# MVP] - 14 Jan 2008 18:55 GMT
To add what Marc says, I don't know that not using an array over a
List<int> is going to be faster here either.  What you should be doing is
pre-allocating what you think you will use (or over, if you have to
approximate) and you should get pretty even performance.

   Of course, the only way to test this is to try.

Signature

         - Nicholas Paldino [.NET/C# MVP]
         - mvp@spam.guard.caspershouse.com

> Hello,
>
[quoted text clipped - 41 lines]
> Thanks,
> Geoffrey
Jon Skeet [C# MVP] - 14 Jan 2008 18:57 GMT
<snip>

> I think this is a really useful pattern, as it is way more efficient
> to deal with such conditions that happen once in a million times.

Not only do I doubt that the performance is likely to be significantly
improved (and there's a big difference between "once in a million" and
the "once in a hundred" you originally state) - there's a massive cost
in readability.

Using exceptions like this is a really, really bad idea. From a
maintenance point of view, it is absolutely horrible. This isn't the
way to get fast code. You should profile the code and attack very
specific bottlenecks, rather than bending your code out of shape like
this without solid performance figures behind you.

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Ignacio Machin ( .NET/ C# MVP ) - 14 Jan 2008 19:06 GMT
Hi,

That is the kind fo programming that should not appear in a performance
critical app. It create uncertainly
It's MUCH better if you use a List<T> with enough space to accomodate the
number of items you are expecting.

You will get the same functionality than by using the array and you avoid
creating an exception.

Signature

Ignacio Machin
http://www.laceupsolutions.com
Mobile & warehouse Solutions.

> Hello,
>
[quoted text clipped - 41 lines]
> Thanks,
> Geoffrey
Peter Bromberg [C# MVP] - 14 Jan 2008 20:24 GMT
I agree with the other responders. At first blush, you seem to be using
exceptions for handling business logic. That's not what they are for. The
idea is to AVOID having exceptions in the first place.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com 

> Hello,
>
[quoted text clipped - 41 lines]
> Thanks,
> Geoffrey
Ben Voigt [C++ MVP] - 18 Jan 2008 16:27 GMT
>I agree with the other responders. At first blush, you seem to be using
> exceptions for handling business logic. That's not what they are for. The
> idea is to AVOID having exceptions in the first place.

The idea is valid, only doesn't work with .NET arrays. Of course it's an
implementation detail that should be well encapsulated from the user.

Exceptions are designed for implementing the unusual case without loading
down the fast path.

For example, the stack (for parameter passing) uses exactly the technique
the OP is discussing.

> -- Peter
> Site: http://www.eggheadcafe.com
[quoted text clipped - 46 lines]
>> Thanks,
>> Geoffrey
Lucas Eagleton - 15 Jan 2008 04:37 GMT
Hi,

I see a lot of people dislike this concept, but perhaps I have something
that may help if you want to go down the track of using arrays etc.
You could take out the count2 stuff if it was only one item added per
execution of the loop.

int currentmax=100;
int count=0;
int count2=0; // used to keep a track of the actual number of items in the
array.
int[] l = new int[currentmax];
while (...)
{
   if (count2 + 'num of items added each time' > currentmax) {
       currentmax += 100;
       // recreate array with new currentmax size.
   }

   l[count++]=f(...);
   count2++;

   l[count*2+1]=f(...);
   count2++;
}

- Lucas.

> Hello,
>
[quoted text clipped - 41 lines]
> Thanks,
> Geoffrey
Ben Voigt [C++ MVP] - 18 Jan 2008 16:24 GMT
> Hello,
>
[quoted text clipped - 38 lines]
> I think this is a really useful pattern, as it is way more efficient
> to deal with such conditions that happen once in a million times.

Trouble is, the OutOfRange exception isn't thrown using hardware support
(access violation exception using vectored handlers) where you could
actually see a performance gain.  Instead, the compiler has to insert the
exact check you are trying to avoid.  So check it yourself, then the
optimizer should remove the redundant checks and all the exception baggage.

It would be a different story if using VirtualAlloc to set up your buffer,
so that out of range accesses hit a guard region and cause a page fault.
But in .NET you'd just be accessing the next object on the gc heap, not
faulting.

> Thanks,
> Geoffrey

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.