he, why not load the whole internet to be safe ;-)... but seriously, this error should be handled in a more appropriate manner, but not by just loading things in advance..
whoops... pressed the wrong button....
....in advance without thinking more thoroughly about the consequences e.g. what if the errorhandler was loaded in advance, but wants to write a processvariable in the db then you have a loop again...
Well, the error handler can do its job inside a try-catch(Exception) and be sure that nothing escapes it. That's what I personally do, in fact.
But if the error handler itself is not available, then it is more like a "framework" problem. Moreover, the exception handler is typically loaded when there IS a problem. One of possible problems may be a database problem, irrespective of how much effort has been put into the correct configuration of the application.
Indeed, loading all classes in advance may be overkill for processes with lots of custom actions and code deployed in the process archive (although I understand deploying lots of code into the database is actually discouraged and I understand why) -- But, leaving ordinary classes aside, how many exception handlers can there be ?
Eager loading or not -- the actual big problem that occurs on general db failure is the infinite loop. Indeed, all that an already-loaded exception handler can do on general db failure is log stuff to log4j but anyway things get logged. So the only real problem remains the loop.