Re: [RFC] Exceptions in the engine

"Pierre Joye" wrote in message news:CAEZPtU7vt=PpK4p3VFZFLAEPzi_wfr2Hr_av+dtzVD6D2dZCSw@mail.gmail.com...

On Feb 21, 2015 2:08 AM, "Tony Marston" <TonyMarston@hotmail.com> wrote:

""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...

On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston <TonyMarston@hotmail.com>

wrote:

I disagree. Exceptions were originally invented to solve the

semipredicate problem which only exists with procedural functions, not object methods. Many OO purists would like exceptions to be thrown everywhere, but this would present a huge BC break. If it were possible get these functions to throw an exception ONLY when they are included in a try ... catch block then this would not break BC at all.

Tony, first of all - this still breaks BC, because exception is being

thrown in a place where it used not to be...

I disagree. The following function calls would not throw exceptions fopen(...); fwrite(...); fclose(...); while the following code would: try {

       fopen(...);
       fwrite(...);
       fclose(...);

} catch (....) {

       ....

}

When some function's result heavily depends on the context it makes said

function much harder to reason about. And creates mental overhead for those who'll have to read the code with this function.

And again, if you need exceptions for fopen please consider using

SplFileObject.

For file usage, yes. But are there any other procedural functions without

an Spl* alternative which would benefit from this technique? Expected failures should not raise exception. For example, IOs are expected to fail (be network, filesystem etc), I would really not be in favor of adding exceptions for similar cases. This is a normal control flow. "Pierre Joye" wrote in message news:CAEZPtU7vt=PpK4p3VFZFLAEPzi_wfr2Hr_av+dtzVD6D2dZCSw@mail.gmail.com...

On Feb 21, 2015 2:08 AM, "Tony Marston" <TonyMarston@hotmail.com> wrote:

""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...

On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston <TonyMarston@hotmail.com>

wrote:

I disagree. Exceptions were originally invented to solve the

semipredicate problem which only exists with procedural functions, not object methods. Many OO purists would like exceptions to be thrown everywhere, but this would present a huge BC break. If it were possible get these functions to throw an exception ONLY when they are included in a try ... catch block then this would not break BC at all.

Tony, first of all - this still breaks BC, because exception is being

thrown in a place where it used not to be...

I disagree. The following function calls would not throw exceptions fopen(...); fwrite(...); fclose(...); while the following code would: try {

       fopen(...);
       fwrite(...);
       fclose(...);

} catch (....) {

       ....

}

When some function's result heavily depends on the context it makes said

function much harder to reason about. And creates mental overhead for those who'll have to read the code with this function.

And again, if you need exceptions for fopen please consider using

SplFileObject.

For file usage, yes. But are there any other procedural functions without

an Spl* alternative which would benefit from this technique? Expected failures should not raise exception. For example, IOs are expected to fail (be network, filesystem etc), I would really not be in favor of adding exceptions for similar cases. This is a normal control flow.

Then why do SplFileInfo::openFile and SplFileObject::__construct throw exceptions if the file cannot be opened? -- Tony Marston