Wow, sounds like poor design to start with. When I first read the question a redesign around Service Broker popped into my head because this is essentially a queuing operation and SB with an activation procedure seems like a good way to handle it, but you probably don't have the opportunity to re-architect it this way.

I can see why you wouldn't want to use a trigger to call the SP because it would fire for each insert and it sounds like you are trying to process the rows in a set-based fashion.

The next thing I would think of is a windows service that is polling the table and when it finds unprocessed rows it runs the SP. I think this will enable you to have "constant" processing and have error handling available through .NET, so that you can log errors and keep the service running so the next timer tick that sets off the processing will still run.

Another option is having the SQLAgent Job run an SSIS package that, like .NET, allows you to handle errors within the package and keep the job running because it will always return success to SQL Agent.