Re: exceptions instead of errors

At 04:12 13.05.2003, John Coggeshall wrote:

On Mon, 2003-05-12 at 21:41, George Schlossnagle wrote: What is the point of having a new error type? How does that differ semantically from just throwing an exception? I discussed this with Shane @ PHP-CON.. It was in the context of throwing exceptions for all E_ERRORs internally, and then having a default catch which trigger the standard E_ERROR. The idea was that errors could be caught then without breaking BC. However, Shane rightly pointed out that the issue with that solution was that although some E_ERRORs could be considered "recoverable" and an exception would make sense, there are some E_ERRORs which simply should cause execution to halt. Since the idea of figuring out which E_ERRORs were catchable and which ones were not was unreasonable, the thought was that the creation of a separate error type that was functionality identical to E_ERROR could be created. This way internally new code could throw exceptions, and it would provide a means for maintainers to roll-into the idea of having exceptions in established extensions without causing any shake-up.

NO exceptions for E_CORE_<whatever> and E_PARSE. and there is really no reason for another error type. the problem lies in the handling of all those errors spit out by our handy c-level utility functions such like open basedir checks and all. And repeated once again: We have two choices (erm three we can f**k up the language and its oo capabilities) first rewrite the whole c-level api to know whether or not an exception should be thrown or not or seconf find an automatic solution as my proposal.

The only way I could see something like this working is exceptions=E_ALL|~E_NOTICE which would throw an exception on all non-notice errors. I think this would be a Bad Idea though, as it is much less intuitive than throwing exceptions on E_ERROR in a try block or when set_exception_handler has set a final exception handler.

AND surely no more ini settings.

Again, the problem with that solution is the concept that some E_ERRORs really shouldn't be thrown as exceptions, while others it'd be useful.

Yes we must fix those places were E_ERROR was used in a wrong way and use another error level instead. regards marcus