Re: exceptions instead of errors

On Tuesday, May 13, 2003, at 10:32 AM, Zeev Suraski wrote:

At 16:35 13/05/2003, George Schlossnagle wrote:

The issue though is that almost none of the E_ERRORs in the engine are actually really fatal.

I haven't counted, but there certainly are many that are fatal.

I agree that the issue of things which are currently E_WARNINGs is complex (I personally think they should be handled by wrapper implementations that throw exceptions or vice-versa, but I think that is an issue for a different discussion), but the E_ERROR behavior change is completely clean and does not jeopardize BC at all.

You mean making E_ERROR's throw exceptions? It jeopardizes stability. We can only do it if we introduce the new error level and selectively change existing E_ERRORs to that error level, iff they don't leave the engine (or other parts of the infrastructure) in an unstable state. We also have to change the default extension handler to be slightly smarter and emit an error message identical to the ones that we emit today, with no traces of "exception" in there - people who don't ask for exceptions shouldn't bump into them.

I agree that stability is critical - that should certainly not be compromised. The engine already has E_CORE_ERROR, which is ideal for uncatchable runtime errors. When I wrote my proof-of-concept patch to do ini-level switching of behavior, I did a quick survey of the existing E_ERRORs, very very few of them needed to be moved to E_CORE_ERROR. Marcus' runtime determination of whether to throw exceptions or use the default error handler is much more clever than my patch though, and goes almost all the way to handling the concerns you present. The default error handler being made smarter is of course a no-brainer as well. George