The feature exists in Python:
http://stackoverflow.com/questions/574730/python-how-to-ignore-an-exception-and-proceed,
in Ruby:
http://stackoverflow.com/questions/5089802/which-is-the-shortest-way-to-silently-ignore-a-ruby-exception.
Just saying.
On Wed, May 1, 2013 at 4:46 AM, Patrick ALLAERT
Hi!
The feature exists in
Python:
http://stackoverflow.com/questions/574730/python-how-to-ignore-an-exception-and-proceed,
I don't think it does what is proposed - except/pass just catches an
exception and does nothing, it does not return in the place where
exception was thrown down the
2013/4/30 Pierre Joye pierre@gmail.com:
hi,
On Tue, Apr 30, 2013 at 7:54 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
You may have a lib/object/chunk of code which raises exceptions, because
its developer thought some error is not recoverable; but when you use
it, you don't want to
2013/4/29 Stas Malyshev smalys...@sugarcrm.com
I agree. If your code can handle the problem, it should not throw. If it
throws, the control should not go back there, since the code already
gave up and declared it can not continue doing whatever it was doing.
Exceptions are meant to handle
Hi!
It's a point of view, not something the language should enforce.
It is a point of view that any proper language should enforce. Languages
always enforce certain style, certain ideas and certain paradigm - be it
computer languages or natural languages. You can decide from now on in
your
hi,
On Tue, Apr 30, 2013 at 7:54 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
You may have a lib/object/chunk of code which raises exceptions, because
its developer thought some error is not recoverable; but when you use
it, you don't want to break your program's execution.
That's why
I think we should look at swapping out the parser for something more
context aware before we start adding more generic keywords that have
global symbol ramifications and has name BC implications.
There is some code (lots?) out there that has:
class SomeClass {
public function resume() {
On Fri, 2013-04-26 at 16:41 +0200, Julien Pauli wrote:
Hello internals,
I had an idea recently with a friend, about a feature try-catch blocks
could use.
Let me just write an example, you will quickly understand the idea :
*?php*
*
*
*try {*
* foo();*
* bar();*
* baz();*
*}
On Sat, 2013-04-27 at 19:46 +0100, Robert Stoll wrote:
I agree with Amaury.
Although, it is rather smelly code to use try/catch as control flow
instrument, in some situations it is clearer to do it this way.
I think the new construct would be especially useful if one just wants to
log
2013/4/28 Julien Pauli jpa...@php.net
On Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard ama...@amaury.net
wrote:
2013/4/27 Ferenc Kovacs tyr...@gmail.com
please don't reuse the continue keyword for it.
There are a bunch of code out there where which uses exceptions in a
loop
Hi Julien,
I'm still on the fence, not sure if it isn’t too opaque.
Am 26.04.2013 um 16:41 schrieb Julien Pauli jpa...@php.net:
[...]
One question regarding scoping: does the next statement inherit the scope of
the catch block like this?
try {
$user = $repository-findById(123);
On Mon, 2013-04-29 at 08:25 +0200, Lars Strojny wrote:
Hi Julien,
I'm still on the fence, not sure if it isn’t too opaque.
Am 26.04.2013 um 16:41 schrieb Julien Pauli jpa...@php.net:
[...]
One question regarding scoping: does the next statement inherit the scope of
the catch block
HI,
I also really don't like it.
if you have a try/catch within a for, will it continue the try or for?
(or have I to use continue 2 to reach the for) At least use another
keyword to make it more clear that you don't want to continue a loop
at the beginning but a catch statement after the
So, in this example, if, say, bar() throws a SomeException , the code
would then resume and execute baz() after the catch block.
Just presenting the idea here, no RFC actually , I'm collecting
thoughts and notices.
It seems like you want application specific flow control (caller
specific)
On Apr 28, 2013, at 17:27, Julien Pauli jpa...@php.net wrote:
On Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard ama...@amaury.net wrote:
2013/4/27 Ferenc Kovacs tyr...@gmail.com
please don't reuse the continue keyword for it.
There are a bunch of code out there where which uses
On Apr 29, 2013, at 09:25, Amaury Bouchard ama...@amaury.net wrote:
Why not. But it will come in addition to resume, not instead of it.
Then:
- resume = continue execution just after the point where the exception was
raised.
- restart = restart the whole try block.
I don't understand
Hi!
this has quite a few issues and feels like abusing exceptions for
regular control flow.
The primary issue is that throw is a terminating operation. A
I agree. If your code can handle the problem, it should not throw. If it
throws, the control should not go back there, since the code
Why not. But it will come in addition to resume, not instead of it.
Then:
- resume = continue execution just after the point where the exception
was raised.
- restart = restart the whole try block.
I don't understand the meaning of your rollback.
2013/4/29 Camilo Sperberg unrea...@gmail.com
On Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard ama...@amaury.net wrote:
2013/4/27 Ferenc Kovacs tyr...@gmail.com
please don't reuse the continue keyword for it.
There are a bunch of code out there where which uses exceptions in a loop
context.
For example you have a retry counter
As Julien said, there is a BC break, when a try/catch block is written
inside a loop. But I think it's not a major usage, and it's a minor
inconvenient.
Yeah, and catching and discarding exceptions also possible, albeit a minor
inconvinience.
I don't have a strong opinion on this
2013/4/27 Ferenc Kovacs tyr...@gmail.com
please don't reuse the continue keyword for it.
There are a bunch of code out there where which uses exceptions in a loop
context.
For example you have a retry counter decremented in a loop and you catch
the exceptions and retry until the retry limit
Sorry but I disagree, I think you're approaching try-catch wrong.
You shouldn't have a try-catch that *can* continue on the next line after
the throw.
What you should do is have decoupled code that handles _their own
exceptions_ nicely and either cleans up after itself else it rethrows the
2013/4/27 Daniel Macedo admac...@gmail.com
Sorry but I disagree, I think you're approaching try-catch wrong.
You shouldn't have a try-catch that *can* continue on the next line after
the throw.
What you should do is have decoupled code that handles _their own
exceptions_ nicely and either
] Continued try blocks
2013/4/27 Daniel Macedo admac...@gmail.com
Sorry but I disagree, I think you're approaching try-catch wrong.
You shouldn't have a try-catch that *can* continue on the next line
after the throw.
What you should do is have decoupled code that handles _their own
exceptions_
Hello internals,
I had an idea recently with a friend, about a feature try-catch blocks
could use.
Let me just write an example, you will quickly understand the idea :
*?php*
*
*
*try {*
* foo();*
* bar();*
* baz();*
*} catch (SomeException $e) {*
*dosomestuff();*
*continue; /*
Sounds interesting. And what about the second attempt passing the try block
without goto?
2013/4/26 Julien Pauli jpa...@php.net
Hello internals,
I had an idea recently with a friend, about a feature try-catch blocks
could use.
Let me just write an example, you will quickly understand the
2013/4/26 Julien Pauli jpa...@php.net
Hello internals,
I had an idea recently with a friend, about a feature try-catch blocks
could use.
Let me just write an example, you will quickly understand the idea :
*?php*
*
*
*try {*
* foo();*
* bar();*
* baz();*
*} catch
On Friday 26 April 2013 16:41:17 Julien Pauli wrote:
*try {*
* foo();*
* bar();*
* baz();*
*} catch (SomeException $e) {*
*dosomestuff();*
*continue; /* Here is the feature, go back to try block */*
*} catch (Exception $e) {*
*dosomething();*
*}*
...
So, in this
I will answer, as the idea came from Pierrick Charron and I :-)
Sometimes, you call functions (or methods) and you know they can throw some
exceptions. But you don't want to stop all computations just because one of
them raised an exception. Maybe you just want to log it, and go to the next
Hi
2013/4/26 Lazare Inepologlou linep...@gmail.com:
This seems like a BC break:
for ( ; ; ) {
try {
...
} catch (Exception $e) {
continue;
}
}
With the proposed syntax, continue will no longer refer to the for loop.
Well, at the moment continue is assigned to only usage
Am 26.04.13 16:41, schrieb Julien Pauli:
Hello internals,
I had an idea recently with a friend, about a feature try-catch blocks
could use.
Let me just write an example, you will quickly understand the idea :
*?php*
*
*
*try {*
* foo();*
* bar();*
* baz();*
*} catch
2013 20:15
An: Julien Pauli
Cc: PHP Internals
Betreff: Re: [PHP-DEV] Continued try blocks
Am 26.04.13 16:41, schrieb Julien Pauli:
Hello internals,
I had an idea recently with a friend, about a feature try-catch blocks
could use.
Let me just write an example, you will quickly understand
2013/4/26 Andreas Heigl andr...@heigl.org
try {
$foo = $bar-getObject();
$foo-doSomething()
} catch(Exception $e) {
continue // Or whatever shall be used
}
When $bar-getObject throws an Exception no $foo is set. So the next
line will result in a PHP Fatal error: Call to a
33 matches
Mail list logo
