Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:
if($condition) {
echo 'foobar';
}
is strictly equivalent to:
if($condition)
echo 'foobar';
But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
First, I would like to know why it is not possible to write:
try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());
as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e->getMessage());
}
Second, if it is possible, could we plan to have this “feature”
(uniformity actually) in PHP6 (or maybe before)?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
Why is your try block only going to contain 1 line, and that's
throwing an exception??
try
throw new Exception('foobar');
catch(Exception $e)
Braces are a good thing, they give structure and stop people from
mis-reading things and writing bugs, the same can be said for the if()
situation.
- Braces are good.
- Try with only one line in it to throw an exception doesn't seem
like a realistic situation.
-1 from me, sorry Hoa.
On Thu, Jul 19, 2012 at 10:44 AM, Ivan Enderlin @ Hoa
ivan.enderlin@hoa-project.net wrote:
Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:if($condition) {
echo 'foobar';
}is strictly equivalent to:
if($condition)
echo 'foobar';But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
First, I would like to know why it is not possible to write:try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e->getMessage());
}Second, if it is possible, could we plan to have this “feature” (uniformity
actually) in PHP6 (or maybe before)?Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/
- Try with only one line in it to throw an exception doesn't seem
like a realistic situation.
It could be something like this:
try
$object->method();
catch (\Exception $e)
return false;
and ->method(), obviously, can have quite a long and complex structure
Why is your try block only going to contain 1 line, and that's
throwing an exception??try
throw new Exception('foobar');
catch(Exception $e)
Because it's a contrived example. He's not trying to write real code, he's trying to demonstrate his point - and you totally missed that point.
Braces are a good thing, they give structure and stop people from
mis-reading things and writing bugs, the same can be said for the if()
situation.
- Braces are good.
This is subjective. There are some cases where it might improve code readability to drop the braces for a single-statement try/catch.
There's certainly no technical barrier to doing this. I'm not familiar with PHP's parser, but I'd imagine there would be some kind of 'statement' non-terminal that would handle single statements as well as a braced group of statements.
- Try with only one line in it to throw an exception doesn't seem
like a realistic situation.
There could be some utility to this. For example, as well as having post-fix if, unless, etc., Ruby also has a post-fix 'rescue'. Here's a silly example of its use:
some_var = foo.bar rescue "oops"
If 'foo.bar' threw an exception, some_var would contain "oops" instead.
I think PHP could benefit from having a single statement try form. I often turn to PHP for quick and dirty scripts when I need to do something with little fuss. I think having try/catch support brace-less single statements would help increase consistency in PHP's syntax, as well as be useful in certain situations.
-1 from me, sorry Hoa.
On Thu, Jul 19, 2012 at 10:44 AM, Ivan Enderlin @ Hoa
<ivan.enderlin@hoa-project.net (mailto:ivan.enderlin@hoa-project.net)> wrote:Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:if($condition) {
echo 'foobar';
}is strictly equivalent to:
if($condition)
echo 'foobar';But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
First, I would like to know why it is not possible to write:try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e->getMessage());
}Second, if it is possible, could we plan to have this “feature” (uniformity
actually) in PHP6 (or maybe before)?Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/
On Thu, Jul 19, 2012 at 10:58 AM, Charlie Somerville
charlie@charliesomerville.com wrote:
Why is your try block only going to contain 1 line, and that's
throwing an exception??try
throw new Exception('foobar');
catch(Exception $e)Because it's a contrived example. He's not trying to write real code, he's
trying to demonstrate his point - and you totally missed that
You're right, I totally missed that point.
Braces are a good thing, they give structure and stop people from
mis-reading things and writing bugs, the same can be said for the if()
situation.
- Braces are good.
This is subjective. There are some cases where it might improve code
readability to drop the braces for a single-statement try/catch.There's certainly no technical barrier to doing this. I'm not familiar with
PHP's parser, but I'd imagine there would be some kind of 'statement'
non-terminal that would handle single statements as well as a braced group
of statements.
Same sentiments as from Rafael, bracket-less is bug-prone.
- Try with only one line in it to throw an exception doesn't seem
like a realistic situation.There could be some utility to this. For example, as well as having post-fix
if, unless, etc., Ruby also has a post-fix 'rescue'. Here's a silly example
of its use:some_var = foo.bar rescue "oops"If 'foo.bar' threw an exception, some_var would contain "oops" instead.
I think PHP could benefit from having a single statement try form. I often
turn to PHP for quick and dirty scripts when I need to do something with
little fuss. I think having try/catch support brace-less single statements
would help increase consistency in PHP's syntax, as well as be useful in
certain situations.-1 from me, sorry Hoa.
On Thu, Jul 19, 2012 at 10:44 AM, Ivan Enderlin @ Hoa
ivan.enderlin@hoa-project.net wrote:Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:if($condition) {
echo 'foobar';
}is strictly equivalent to:
if($condition)
echo 'foobar';But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
First, I would like to know why it is not possible to write:try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e->getMessage());
}Second, if it is possible, could we plan to have this “feature” (uniformity
actually) in PHP6 (or maybe before)?Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/
On Thu, Jul 19, 2012 at 11:58 AM, Charlie Somerville <
charlie@charliesomerville.com> wrote:
Why is your try block only going to contain 1 line, and that's
throwing an exception??try
throw new Exception('foobar');
catch(Exception $e)Because it's a contrived example. He's not trying to write real code, he's
trying to demonstrate his point - and you totally missed that point.
In this case the removal of brackets would surely limit this to one line,
so any examples or use cases would look the same.
Braces are a good thing, they give structure and stop people from
mis-reading things and writing bugs, the same can be said for the if()
situation.
- Braces are good.
This is subjective. There are some cases where it might improve code
readability to drop the braces for a single-statement try/catch.
It would cause code maintainability problems and unexpected outputs in
error cases, just like if's do.
There's certainly no technical barrier to doing this. I'm not familiar
with PHP's parser, but I'd imagine there would be some kind of 'statement'
non-terminal that would handle single statements as well as a braced group
of statements.
- Try with only one line in it to throw an exception doesn't seem
like a realistic situation.There could be some utility to this. For example, as well as having
post-fix if, unless, etc., Ruby also has a post-fix 'rescue'. Here's a
silly example of its use:some_var = foo.bar rescue "oops"If 'foo.bar' threw an exception, some_var would contain "oops" instead.
a rescue method is a complete other thing, sounds interesting, but has no
reference to bracket-less try blocks.
I think PHP could benefit from having a single statement try form. I often
turn to PHP for quick and dirty scripts when I need to do something with
little fuss. I think having try/catch support brace-less single statements
would help increase consistency in PHP's syntax, as well as be useful in
certain situations.
I think bracket-less is a bad practice that was left for BC, i would rather
we move away from it then move more things into it.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Hi,
2012/7/19 Paul Dragoonis dragoonis@gmail.com
Why is your try block only going to contain 1 line, and that's
throwing an exception??try
throw new Exception('foobar');
catch(Exception $e)Braces are a good thing, they give structure and stop people from
mis-reading things and writing bugs, the same can be said for the if()
situation.
- Braces are good.
- Try with only one line in it to throw an exception doesn't seem
like a realistic situation.
try $this->foobar(); catch ($e) {
// Much amount of error handling
}
// or maybe
try $this->foobar(); catch ($e) $this->handleException($e);
OK, the first example is better, but both reads like quite nice :)
try someVeryDifficultStuff(); catch ($e) { /* handle */ }
Regards,
Sebastian
-1 from me, sorry Hoa.
On Thu, Jul 19, 2012 at 10:44 AM, Ivan Enderlin @ Hoa
ivan.enderlin@hoa-project.net wrote:Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:if($condition) {
echo 'foobar';
}is strictly equivalent to:
if($condition)
echo 'foobar';But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
First, I would like to know why it is not possible to write:try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e->getMessage());
}Second, if it is possible, could we plan to have this “feature”
(uniformity
actually) in PHP6 (or maybe before)?Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/
On Thu, Jul 19, 2012 at 11:44 AM, Ivan Enderlin @ Hoa <
ivan.enderlin@hoa-project.net> wrote:
Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:if($condition) {
echo 'foobar';
}is strictly equivalent to:
if($condition)
echo 'foobar';But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
Writing if blocks without brakets is considered a bad practice. IMHO anyway.
First, I would like to know why it is not possible to write:
try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());
This has code readability problem written all over it. When maintaining it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.
as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e->getMessage());
}Second, if it is possible, could we plan to have this “feature”
(uniformity actually) in PHP6 (or maybe before)?
Sorry, -1 from me.
This has code readability problem written all over it. When maintaining it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.
I've often heard people make this argument, but I've never found it to be a real concern in practise.
Is this really such a common problem?
On Thu, Jul 19, 2012 at 11:44 AM, Ivan Enderlin @ Hoa <
ivan.enderlin@hoa-project.net (mailto:ivan.enderlin@hoa-project.net)> wrote:Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:if($condition) {
echo 'foobar';
}is strictly equivalent to:
if($condition)
echo 'foobar';But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.Writing if blocks without brakets is considered a bad practice. IMHO anyway.
First, I would like to know why it is not possible to write:
try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());This has code readability problem written all over it. When maintaining it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e->getMessage());
}Second, if it is possible, could we plan to have this “feature”
(uniformity actually) in PHP6 (or maybe before)?Sorry, -1 from me.
On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville <
charlie@charliesomerville.com> wrote:
This has code readability problem written all over it. When maintaining it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.I've often heard people make this argument, but I've never found it to be
a real concern in practise.Is this really such a common problem?
I have seen this problem happen, people losing time trying to figure out
what is wrong only to find
its a missing bracket.
As Paul said, this is bug-prone.
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
On Thu, Jul 19, 2012 at 11:06 AM, Rafael Dohms listas@rafaeldohms.com.brwrote:
On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville <
charlie@charliesomerville.com> wrote:This has code readability problem written all over it. When maintaining
it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.I've often heard people make this argument, but I've never found it to be
a real concern in practise.Is this really such a common problem?
I have seen this problem happen, people losing time trying to figure out
what is wrong only to find
its a missing bracket.
As Paul said, this is bug-prone.
Other bracket-less blocks allow authors to shoot themselves in the foot
equally so, yet PHP supports these as well. The actual problem here is an
inconsistency in the parser, which I'd consider to be a bug.
Peter
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
+1 for the consistency of it. It's surprising that:
if ($foo)
return $bar;
else
return 42;
works and:
try
maybe_dangerous();
catch(Dynamite $e)
handle_error();
does not.
On Thu, Jul 19, 2012 at 11:06 AM, Rafael Dohms listas@rafaeldohms.com.brwrote:
On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville <
charlie@charliesomerville.com> wrote:This has code readability problem written all over it. When maintaining
it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.I've often heard people make this argument, but I've never found it to be
a real concern in practise.Is this really such a common problem?
I have seen this problem happen, people losing time trying to figure out
what is wrong only to find
its a missing bracket.
As Paul said, this is bug-prone.Other bracket-less blocks allow authors to shoot themselves in the foot
equally so, yet PHP supports these as well. The actual problem here is an
inconsistency in the parser, which I'd consider to be a bug.Peter
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Hi，
在 2012年7月19日星期四，下午6:45，Rune Kaagaard 写道：
+1 for the consistency of it. It's surprising that:
if ($foo)
return $bar;
else
return 42;works and:
try
maybe_dangerous();
catch(Dynamite $e)
handle_error();
There is no condition after try, it's really hard to read without bracket.
it becomes even worse if it didn't format pretty as above.
does not.
On Thu, Jul 19, 2012 at 11:06 AM, Rafael Dohms <listas@rafaeldohms.com.br (mailto:listas@rafaeldohms.com.br)>wrote:
On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville <
charlie@charliesomerville.com (mailto:charlie@charliesomerville.com)> wrote:This has code readability problem written all over it. When maintaining
it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.I've often heard people make this argument, but I've never found it to be
a real concern in practise.Is this really such a common problem?
I have seen this problem happen, people losing time trying to figure out
what is wrong only to find
its a missing bracket.
As Paul said, this is bug-prone.Other bracket-less blocks allow authors to shoot themselves in the foot
equally so, yet PHP supports these as well. The actual problem here is an
inconsistency in the parser, which I'd consider to be a bug.Peter
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
2012/7/19 Reeze reeze.xia@gmail.com
在 2012年7月19日星期四，下午6:45，Rune Kaagaard 写道：
+1 for the consistency of it. It's surprising that:
if ($foo)
return $bar;
else
return 42;works and:
try
maybe_dangerous();
catch(Dynamite $e)
handle_error();There is no condition after
try, it's really hard to read without
bracket.
it becomes even worse if it didn't format pretty as above.
Bad argument. It's not about the presence of a condition after "try". It's
about language consistency.
If you were right, we shouldn't be able to write that:
$i = 0;
do
echo($i++);
while ($i < 3);
PHP allows it. Nobody cares about it, while I think it's a very ugly
writing. But everybody is accustomed to it, because it's inherited from C
syntax.
And bracketless try/catch doesn't exists in other languages, so it
shouldn't exists in PHP?
More, do not confuse coding conventions (depends on people, changes from
time to time) and language syntax (should be stable and consistent).
I don't think we should add it purely for consistency, because then we'd
have to allow nonsense like:
switch x;
case 1;
endcase;
endswitch;
or...
try;
x;
catch e;
endtry;
Sure, consistency is good, but this would allow sloppy code.
2012/7/19 Reeze reeze.xia@gmail.com
在 2012年7月19日星期四，下午6:45，Rune Kaagaard 写道：
+1 for the consistency of it. It's surprising that:
if ($foo)
return $bar;
else
return 42;works and:
try
maybe_dangerous();
catch(Dynamite $e)
handle_error();There is no condition after
try, it's really hard to read without
bracket.
it becomes even worse if it didn't format pretty as above.Bad argument. It's not about the presence of a condition after "try". It's
about language consistency.
If you were right, we shouldn't be able to write that:
$i = 0;
do
echo($i++);
while ($i < 3);PHP allows it. Nobody cares about it, while I think it's a very ugly
writing. But everybody is accustomed to it, because it's inherited from C
syntax.
And bracketless try/catch doesn't exists in other languages, so it
shouldn't exists in PHP?More, do not confuse coding conventions (depends on people, changes from
time to time) and language syntax (should be stable and consistent).
Hi all,
After a day and a quite lot of (hot) answers, we can state that making
try/catch braces optional has a weak probability to appear in PHP. But…
This discussion shows a leak of consistency in the PHP syntax regarding
braces. Language constructions (restricted to control structures) such
as: if, else, elseif, while, do/while, for, foreach, see their braces as
optional. And other more “complex” language constructions (that were
introduced some years later) such as: try/catch and switch/case, see
their braces required.
I assume that making braces optional for switch/case is very strange.
It's really a block of cases. If you have only one case instruction in
your switch, maybe you should rewrite it.
But the case (no joke) of try/catch is different. Most of the people who
were against my “proposal” said it is “error-prone”, it will introduce
“bugs that hard to detect”. But… wait, PHP has goto (and who use it?)!
No kidding, PHP allows you to write very nice code quickly. It is
entirely part of the developer to adopt its own coding rules, but PHP
has made choices in the past and it results in an inconsistency
regarding to its syntax. We should take a decision: either make all
braces required but we all know that it is not possible due to backward
compatibility, either make all braces optional when it is necessary.
Making braces optional for try/catch does:
- not break backward compatibility;
- add consistency in the PHP syntax;
± offer a new way to write buggy programs but no more than with other
control structures (think about goto ;-)).
I see more + than - here. Am I wrong?
Moreover, in parallel, a new idea has been landing: introducing the
“rescue” keyword as a shortcut/replacement of try/catch, such as:
$foo = callThatCouldThrow() rescue 'oof';
Is it possible to chain it, such as:
$foo = callThatCouldThrow() rescue anotherCallThatCouldThrow() rescue
'oof?';
Maybe we should start another topic because it could be a nice idea.
Finally, I would like to clarify my proposal: I just wanted to discuss
about making try/catch braces optional and not criticize PHP syntax…
Best regards :-).
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
Ivan Enderlin @ Hoa wrote:
Finally, I would like to clarify my proposal: I just wanted to discuss about
making try/catch braces optional and not criticize PHP syntax…
The problem here is rather, could we make brackets compulsory everywhere? No
because of BC problems, but this might be the preferred approach by many. So
adding another possible bug creating area does not seem appropriate?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Ivan Enderlin @ Hoa wrote:
Finally, I would like to clarify my proposal: I just wanted to
discuss about
making try/catch braces optional and not criticize PHP syntax…The problem here is rather, could we make brackets compulsory
everywhere? No because of BC problems, but this might be the preferred
approach by many. So adding another possible bug creating area does
not seem appropriate?
Not everywhere :-). All I have pointed out here is adding consistency to
control structures, because they are the only language constructions
impacted by optional brackets.
I very well understand that spreading optional brackets to the entire
langage is not a good idea. I have never mentioned this possibility.
Cheers.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
Ivan Enderlin @ Hoa wrote:
Finally, I would like to clarify my proposal: I just wanted to
discuss about
making try/catch braces optional and not criticize PHP syntax…
I don't see how making something worse because of consistency has any
real benefit besides attacking a perceived problem of inconsistency.
This might be me (quick poll on developers with sample size: 1), but in
all the years of doing PHP/Java/x I hadn't even thought once of trying
to use try/catch without braces. I can't even remember using if without
braces.
Greetings,
Florian
Making braces optional for try/catch does:
- not break backward compatibility;
- add consistency in the PHP syntax;
± offer a new way to write buggy programs but no more than with other control structures (think about goto ;-)).I see more + than - here. Am I wrong?
You are not wrong. This is the inconsistency and it makes sense to fix it.
We are definitely not going to "unfix" it for if/else, so I "+1" your proposal in advance
Moreover, in parallel, a new idea has been landing: introducing the “rescue” keyword as a shortcut/replacement of try/catch, such as:
$foo = callThatCouldThrow() rescue 'oof';
Is it possible to chain it, such as:
$foo = callThatCouldThrow() rescue anotherCallThatCouldThrow() rescue 'oof?';Maybe we should start another topic because it could be a nice idea.
I don't see value in this. "finally" would be much more valuable.
try {
doSomething();
} catch (\Exception $e) {
handleException();
} finally {
genericCleanup() // called if everything is good, if everything is bad or even if exception is rethrown
}
Peter Beverloo wrote:
Other bracket-less blocks allow authors to shoot themselves in the foot
equally so, yet PHP supports these as well. The actual problem here is an
inconsistency in the parser, which I'd consider to be a bug.
Having been caught out too many times now when adding an extra part to code
there 99% of the blocks are correctly wrapped ... when I see code without the
brackets they get added! The bug as far as I am concerned is NOT reporting them
missing but just getting them displayed in eclipse would do me for now ;)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
This reminds me of
$var = something or die();
So if you do follow with braceless-try, I would have
try something() catch($e) do_something_with($e);
Or (a bit simpler, but assumes we have a new pseudovariable $e),
try something() or do_something_with($e)
I don't like the form with a semicolon, because what if there are two
semi-colons after the statement? What does the try statement wrap?
try something();; catch ($e) { ... }
The whole concept breaks away from the tradition of wrapping massive
blocks with try { } statements, and might make applications use
exceptions a LOT more freely. Something to keep in mind.
Jevon
Peter Beverloo wrote:
Other bracket-less blocks allow authors to shoot themselves in the foot
equally so, yet PHP supports these as well. The actual problem here is an
inconsistency in the parser, which I'd consider to be a bug.Having been caught out too many times now when adding an extra part to code
there 99% of the blocks are correctly wrapped ... when I see code without
the brackets they get added! The bug as far as I am concerned is NOT
reporting them missing but just getting them displayed in eclipse would do
me for now ;)--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I have seen this problem happen, people losing time trying to figure out
what is wrong only to find
its a missing bracket.
As Paul said, this is bug-prone.Other bracket-less blocks allow authors to shoot themselves in the foot
equally so, yet PHP supports these as well. The actual problem here is an
inconsistency in the parser, which I'd consider to be a bug.Peter
PHP doesn't support optional brackets on functions, either; please no
one suggest that.
Yes, it's inconsistent that some structures allow short-circuited
brackets. The solution isn't to let all structures have the
bug-attracting syntax. If it wouldn't break a few zillion lines of
existing code I'd say we should resolve the inconsistency by making the
braces required on if/foreach/etc. PHP only has them optional due to a
C/C++ legacy, which may have made sense when the byte size of source
code actually mattered for storage efficiency.
Yes, I have run into bugs that were caused by people forgetting braces.
Yes, I have introduced bugs without realizing it because someone left
off a brace and I didn't notice it. Yes, I now always add braces when
looking at someone's code; I can't even read it otherwise anymore. Any
respectable coding standard requires the otherwise-optional braces.
And yes, I always close my </p> tags as well, and so should you! :-)
--Larry Garfield
Always close <p>, but never close <li> :)
I have seen this problem happen, people losing time trying to figure out
what is wrong only to find
its a missing bracket.
As Paul said, this is bug-prone.Other bracket-less blocks allow authors to shoot themselves in the foot
equally so, yet PHP supports these as well. The actual problem here is an
inconsistency in the parser, which I'd consider to be a bug.Peter
PHP doesn't support optional brackets on functions, either; please no one
suggest that.Yes, it's inconsistent that some structures allow short-circuited
brackets. The solution isn't to let all structures have the bug-attracting
syntax. If it wouldn't break a few zillion lines of existing code I'd say
we should resolve the inconsistency by making the braces required on
if/foreach/etc. PHP only has them optional due to a C/C++ legacy, which
may have made sense when the byte size of source code actually mattered for
storage efficiency.Yes, I have run into bugs that were caused by people forgetting braces.
Yes, I have introduced bugs without realizing it because someone left off
a brace and I didn't notice it. Yes, I now always add braces when looking
at someone's code; I can't even read it otherwise anymore. Any respectable
coding standard requires the otherwise-optional braces.And yes, I always close my </p> tags as well, and so should you! :-)
--Larry Garfield
There is no such thing as an optional closing tag or brace. There's
only lazy and sloppy coders, and parsers that encourage them.
--Larry Garfield
Always close <p>, but never close <li> :)
I have seen this problem happen, people losing time trying to figure out
what is wrong only to find
its a missing bracket.
As Paul said, this is bug-prone.Other bracket-less blocks allow authors to shoot themselves in the foot
equally so, yet PHP supports these as well. The actual problem here is an
inconsistency in the parser, which I'd consider to be a bug.Peter
PHP doesn't support optional brackets on functions, either; please no one
suggest that.Yes, it's inconsistent that some structures allow short-circuited
brackets. The solution isn't to let all structures have the bug-attracting
syntax. If it wouldn't break a few zillion lines of existing code I'd say
we should resolve the inconsistency by making the braces required on
if/foreach/etc. PHP only has them optional due to a C/C++ legacy, which
may have made sense when the byte size of source code actually mattered for
storage efficiency.Yes, I have run into bugs that were caused by people forgetting braces.
Yes, I have introduced bugs without realizing it because someone left off
a brace and I didn't notice it. Yes, I now always add braces when looking
at someone's code; I can't even read it otherwise anymore. Any respectable
coding standard requires the otherwise-optional braces.And yes, I always close my </p> tags as well, and so should you! :-)
--Larry Garfield
HTML5 allow omitting head, body, html (they had no fundamental differences
in parsing IRL), and also quotes and some end tags. Makes for much, much
nicer HTML, e.g.:
<!doctype html>
<meta charset=utf-8> <title>hello</title> <h1>hi</h1> <ul> <li>item 1 <li>item 2 </ul>...that's off-topic though. I don't think we should have more tolerance of
omitted braces in PHP. If you desparately want them, write CoffeeScript
except for PHP (RasmusScript?)
There is no such thing as an optional closing tag or brace. There's only
lazy and sloppy coders, and parsers that encourage them.--Larry Garfield
Always close <p>, but never close <li> :)
I have seen this problem happen, people losing time trying to figure
outwhat is wrong only to find
its a missing bracket.
As Paul said, this is bug-prone.Other bracket-less blocks allow authors to shoot themselves in the
foot
equally so, yet PHP supports these as well. The actual problem here is
an
inconsistency in the parser, which I'd consider to be a bug.Peter
PHP doesn't support optional brackets on functions, either; please no one
suggest that.Yes, it's inconsistent that some structures allow short-circuited
brackets. The solution isn't to let all structures have the
bug-attracting
syntax. If it wouldn't break a few zillion lines of existing code I'd
say
we should resolve the inconsistency by making the braces required on
if/foreach/etc. PHP only has them optional due to a C/C++ legacy, which
may have made sense when the byte size of source code actually mattered
for
storage efficiency.Yes, I have run into bugs that were caused by people forgetting braces.
Yes, I have introduced bugs without realizing it because someone left
off
a brace and I didn't notice it. Yes, I now always add braces when
looking
at someone's code; I can't even read it otherwise anymore. Any
respectable
coding standard requires the otherwise-optional braces.And yes, I always close my </p> tags as well, and so should you! :-)
--Larry Garfield
2012/7/19 Rafael Dohms listas@rafaeldohms.com.br
On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville <
charlie@charliesomerville.com> wrote:This has code readability problem written all over it. When maintaining
it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.I've often heard people make this argument, but I've never found it to be
a real concern in practise.Is this really such a common problem?
I have seen this problem happen, people losing time trying to figure out
what is wrong only to find
its a missing bracket.
As Paul said, this is bug-prone.
Just curious (once more): How can anyone overlook, that the brackets are
intentionally omitted here?
if ($x) {
// Do something
} else return null;
Of course it's a matter of code style [1], but one can write the ugliest
code with every syntax. This argument about "bug-prone" often confuses me,
because I for myself never had such a problem. I also never knew someone,
who had a problem with bracket-less blocks (but must say, that most write
blocks with brackets, thus they may have problems). I've often just
heard this "its bug-prone" (that sounds to me like "there are inattentive
devs out there" to me :X) as as killer argument...
At the end of the day I don't really care wether I should avoid
bracket-less blocks, or not, but ... it's this argument that annoys me :X
And I just think this just looks cute :)
try $calculator->calculateSomeVeryDifficultStuff() catch ($e) {
// on failure
}
2cent and so on
Regards,
Sebastian
[1] I would wrap "return null;" in brackets too, if the line gets too long.
if ($x) {
// Do something
} else {
return someVeryLongStatement() && andSuch();
}
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Sebastian Krebs wrote:
Of course it's a matter of code style [1], but one can write the ugliest
code with every syntax. This argument about "bug-prone" often confuses me,
because I for myself never had such a problem. I also never knew someone,
who had a problem with bracket-less blocks (but must say, that most write
blocks_with_ brackets, thus they_may_ have problems). I've often just
heard this "its bug-prone" (that sounds to me like "there are inattentive
devs out there" to me :X) as as killer argument...
10 years in to development work on projects combining library code from many
sources, The indenting tends to get messed up over time, and it CAN be difficult
to spot that the brackets are missing from a block. In addition to adding them
as I spot missing ones, the indentation will also get tidied up to make things
readable again. The latest injection problem I had reported turned out to be in
the smarty library. The fix involved tidying the layout just to make sure I was
in the right place when fixing it. ( 'highlight' would quite happily pass nasty
code! ) It's all this code, the authors of which have now retired to an easier
live which we have to maintain going forward :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Probably not so much in PHP but I've had some real doozers in my time due this.
For example in C...
if (somethingsFailed)
DEBUG_MACRO("Something failed!");
var = 1;
And then someone un-defines DEBUG_MACRO.
Fun then ensues.
Melanie
I've often heard people make this argument, but I've never found it to be a real concern in practise.
Is this really such a common problem?
For all the reasons already stated, most explicitly because it make the
code ugly as sin, my vote is somewhere between "No", and "Hell No."
-1 on bracketless try/catch
On Thu, Jul 19, 2012 at 2:44 AM, Ivan Enderlin @ Hoa <
ivan.enderlin@hoa-project.net> wrote:
Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:if($condition) {
echo 'foobar';
}is strictly equivalent to:
if($condition)
echo 'foobar';But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
First, I would like to know why it is not possible to write:try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e->getMessage());
}Second, if it is possible, could we plan to have this “feature”
(uniformity actually) in PHP6 (or maybe before)?Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/
Hi Ivan,
try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());
If you use try/catch that much, that you begin to think about the
syntax, you have an architecture- or design-problem.
PS: And if without brackets should be forbidden.
--
Alex Aulbach
If you use try/catch that much, that you begin to think about the
syntax, you have an architecture- or design-problem.
"Easier to ask for forgiveness than permission."
That's one thing I like about python: exceptions everywhere. Much cleaner than
having to use empty/isset/*_exists all the time.
PS: And if without brackets should be forbidden.
Enforcing coding style should be forbidden.
I never use brackets with 'if' if I don't have to because I find it more
readable, but I would never think about changing the language to make everyone
use what I use (especially for such a trivial thing).
--
Léo Peltier
Enforcing coding style should be forbidden.
Clearly you don't work in a team or contribute to Open Source projects.
That's what coding styles are for, keeping code looking the same to make
readability easier for not-you developers.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Hi Ivan,
try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());
If you use try/catch that much, that you begin to think about the
syntax, you have an architecture- or design-problem.
Not sure about that. First, it was an example. Second, it happens more
often than you think. For example, if you're writing a dispatcher (i.e.
redirect some data to some callables), you will want to catch exception
as early as possible. This is not an architecture- or design-issue, this
happens sometimes when you code.
And I would like to point that this is not the topic. The topic is
consistency in PHP syntax (restricted to control structures and
brackets/braces).
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
2012/7/20 Ivan Enderlin @ Hoa ivan.enderlin@hoa-project.net:
If you use try/catch that much, that you begin to think about the
syntax, you have an architecture- or design-problem.Not sure about that. First, it was an example. Second, it happens more often
than you think. For example, if you're writing a dispatcher (i.e. redirect
some data to some callables), you will want to catch exception as early as
possible.
And you misunderstood me: My first thought of removing bracelets was,
that someone could need this, because he has hundreds of
try/catch-blocks and just want to spare some typing.
My thinking is: If someone needs that much try/catch that he begins to
think about syntax, he has definitely another problem
(architecture/design).
This is not an architecture- or design-issue, this happens
sometimes when you code.
It's always so, but it's not a reason for another syntax. :)
And I would like to point that this is not the topic. The topic is
consistency in PHP syntax (restricted to control structures and
brackets/braces).
No, that's exactly the point. :) The reason why we have different
syntaxes is, that it was introduced in PHP/FI, about 16 yreas ago. I
cannot remember the exact timings, but Rasmus experimented a lot with
the syntax and everybody was glad, when the C-syntax has been
implemented - but the old syntax-stuff remained and was quite buggy
and very obfuscating. This was fixed with PHP3. That's why we have
syntaxes without bracelets, everybody liked it, because we could say
"haha, you perl-guys, you C-junkies, we've more ways to program an
if".
That's about 16 (?) year ago and perhaps I mixed it a lttle bit up.
But nowadays it's no question, that brackets are good. But at that
time continental-European programmers tend not using bracelets,
because they are so difficult to type. :)
In other words: You want to introduce something, which we are glad not
to need anymore. :)
--
Alex Aulbach
In other words: You want to introduce something, which we are glad not
to need anymore. :)
Ok. And as I said, it is a proposal so… ;-).
Next topic: rescue or finally keywoard?
Best regards :-).
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
rescue is the exact same concept as catch
On Jul 24, 2012 3:41 PM, "Ivan Enderlin @ Hoa" <
ivan.enderlin@hoa-project.net> wrote:
In other words: You want to introduce something, which we are glad not
to need anymore. :)Ok. And as I said, it is a proposal so… ;-).
Next topic: rescue or finally keywoard?
Best regards :-).
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/
2012.07.24. 7:41, "Ivan Enderlin @ Hoa" ivan.enderlin@hoa-project.net ezt
írta:
In other words: You want to introduce something, which we are glad not
to need anymore. :)Ok. And as I said, it is a proposal so… ;-).
Next topic: rescue or finally keywoard?
For finally see https://bugs.php.net/bug.php?id=32100
it seems that the core devs don't like the idea, but that feature request
seems to have a lot of supporters, and comes up frequently.
Hi!
For finally see https://bugs.php.net/bug.php?id=32100
it seems that the core devs don't like the idea, but that feature request
seems to have a lot of supporters, and comes up frequently.
I haven't seen it come with a pull req though ;) BTW, look at how
finally is implemented in Java, for example, to see why it may not be
that easy to do it properly. But if somebody would provide the RFC with
a patch, we could discuss it and run a vote and see if it has any
support now or not.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
For finally see https://bugs.php.net/bug.php?id=32100
it seems that the core devs don't like the idea, but that feature request
seems to have a lot of supporters, and comes up frequently.I haven't seen it come with a pull req though ;) BTW, look at how
finally is implemented in Java, for example, to see why it may not be
that easy to do it properly. But if somebody would provide the RFC with
a patch, we could discuss it and run a vote and see if it has any
support now or not.
I will implement one.
thanks
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Laruence Xinchen Hui
http://www.laruence.com/
2012/7/20 Alex Aulbach alex.aulbach@gmail.com
PS: And if without brackets should be forbidden.
If I wanted a coding style-constrained language, I would use Python.
Python isn't coding-style constrained, it just uses increases and decreases
whitespace as part of the block syntax. It has considerable flexibility,
but not PHP/Perl-level.
2012/7/20 Alex Aulbach alex.aulbach@gmail.com
PS: And if without brackets should be forbidden.
If I wanted a coding style-constrained language, I would use Python.
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:if($condition) {
echo 'foobar';
}is strictly equivalent to:
if($condition)
echo 'foobar';But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
First, I would like to know why it is not possible to write:try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e->getMessage());
}Second, if it is possible, could we plan to have this “feature”
(uniformity actually) in PHP6 (or maybe before)?
I'd hesitate to call this a feature. If anything, for PHP6, I'd
recommend the opposite: getting rid of brace-less blocks, period.
I've read through the thread, and those proposing it talk about code
readability, and use the argument "I've never had a problem before." To
me, this means you've either (a) not been developing very long, and/or
(b) not been working in long-lived projects, and/or (c) do not work with
other people. Omitting braces makes understanding the intent of the
code harder (did the author intend to only execute one statement, or did
they forget the braces?), makes maintenance harder (a developer needing
to add extra statements now also has to add the braces), and leads to
hard-to-detect bugs (see previous two points).
I've run into problems with brace-less blocks many, many times over
the years. Clearly, enough other people have as well that any serious
coding standard includes a clause requiring that all blocks use
braces. I see no reason to add another context in which braces could
be omitted.
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Matthew Weier O'Phinney wrote:
I've run into problems with brace-less blocks many, many times over
the years. Clearly, enough other people have as well that any serious
coding standard includes a clause requiring that all blocks use
braces. I see no reason to add another context in which braces could
be omitted.
It's nice to hear that it is not only me ...
Brought to mind a problem that popped up in a patch earlier this year. Not my
patch, but the contributor had missed that brackets were missing, and his fix
worked for him, but the following statement was now enabled in the wrong place.
FORTUNATELY this was manually merged, and the mistake spotted, but with the
increasing use of automatic merges ... I think I would support making brackets
compulsory.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi!
I've run into problems with brace-less blocks many, many times over
the years. Clearly, enough other people have as well that any serious
coding standard includes a clause requiring that all blocks use
braces. I see no reason to add another context in which braces could
be omitted.
Agree, no reason to mess with try/catch at all. However for if there's a
small number of cases where brace-less block if ok, e.g. usually I could
write something like:
foreach($arr as $item) {
if(!good($item)) continue;
do_stuff($item);
}
and it's not that bad to have it brace-less. However anything more than
one-term continue or return or break something like that and you want
braces. Of course, this does not apply to try/catch since nobody does
just "return" inside try-catch.
In any case, I don't see any reason to mess with the braces. There's no
problem we'd be solving and it will only bring trouble and more messy code.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227