Re: exceptions instead of errors

At 17:44 13/05/2003, George Schlossnagle wrote:

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.

No it isn't. E_CORE_ERROR is for startup errors, so critical that even our IO mechanism may not be started yet. E_ERROR should remain what it is, we need something new.

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.

I'm not sure how you can determine that, in many cases the reason for the unstable state may be quite far from being trivial. We'd have to do things the other way around - keep everything as E_ERROR, and slowly examine each and every case, and move it to the new error level once we're sure that there'd be no negative side effects.

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.

Unless I'm missing something Marcus' patch only deals with non fatal errors. But if I am missing something and it somehow tries to be smart about E_ERRORs - it shouldn't, whether or not an error is fatal should be left entirely to the author of the error call... Zeev