Re: [VOTE] Allowing use of exceptions in the engine

From: Date: Mon, 09 Dec 2013 18:25:39 +0000
Subject: Re: [VOTE] Allowing use of exceptions in the engine
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-70565@lists.php.net to get a copy of this message
On Dec 9, 2013 8:09 PM, "Nikita Popov" <nikita.ppv@gmail.com> wrote: > > On Mon, Dec 9, 2013 at 4:39 PM, Pierre Joye <pierre.php@gmail.com> wrote: >> >> I do not mind having it in 5.x or 6. but I do mind introducing >> exceptions in the core without defining what we want. Baby steps are >> nice but where do we stop at this stage then? Can we use exceptions in >> extensions as well? Or in other parts of the engine? This is a very >> good move forward but also a very critical move. We need to clarify >> how we do it, where it can be done, naming or how we want them >> exactly, etc. >> >> That's why I can't vote yes with this exact proposal (and its state). > > > Is there something particular that you would like to have clarified or specified? I tried to keep the scope narrow - only engine and only fatal errors, but if you wish to have stricter specification on some parts, please say so. I would prefer to see introduce exceptions in the whole core and clearly define how we want them or where. Adding very good documentation is also a requirement (see Zeev's reply). Not doing may lead to half backed support with everyone doing its little sauce and will end as a big mess. We should avoid that. > About your particular questions: > > > > Can we use exceptions in extensions as well? > This RFC is only about the engine - it does not affect our standard library exts. The rules there stay the same: Functions throw warnings/notices, methods may throw exceptions. Right, everyone does his thing and it is not confusing and inconsistent. Let solve the whole thing instead of a rather limited and not so useful. > > > Or in other parts of the engine? > What do you mean by "other parts"? I'm referring to the Zend engine as a whole, though primarily the executor, because converting compile-time errors will require more careful planning. As of other errors, functions, operators, etc. Cheers, Pierre

« previous php.internals (#70565) next »