Timeouts are scheduled for the bean by the bean. The container provides and delivers the times to the bean. In this special case, the Container *IS* the client that invokes the timeout method, and thus, deals with exception thrown. Since the container is the client, why wouldnt you want it to nuke the bean instance if an exception is thrown?
You cant use timeouts to interrupt a client-call thread. Why? Because the timer might fire onto just one of many pooled stateless session bean instances. Further, you cant do thread control inside the bean method!
If you dont want the bean to nuke, then catch any possible exceptions inside your @timeout method and send them to your logger.
Remember what timers were put there for. They are there to support scheduling jobs to be run in the future. So, lets say you want the container to execute jobs out batch - for instance you might want to sweep the database for customers that are 30 days past due every day and change some column value for those rows. You can do THAT with timers. Just setup a stateless session bean to hold all the business logic. Put the "business" in the timeout method. You'll a method on the batch-job-stateless bean to call that will cause the bean to post a timeout on itself. Away you go!