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 st
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 w
2013/4/30 Pierre Joye :
> hi,
>
> On Tue, Apr 30, 2013 at 7:54 PM, Stas Malyshev 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.
hi,
On Tue, Apr 30, 2013 at 7:54 PM, Stas Malyshev 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 you have try/catc
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 lang
2013/4/29 Stas Malyshev
> 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 exceptional situations
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
>
> On Apr
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 a
On Apr 29, 2013, at 09:25, Amaury Bouchard 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 the m
On Apr 28, 2013, at 17:27, Julien Pauli wrote:
> On Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard wrote:
>
>> 2013/4/27 Ferenc Kovacs
>>
>>> 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
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) wh
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 excep
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 :
> [...]
>
> One question regarding scoping: does the next statement inherit the scope of
> the catch block like this
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 :
[...]
One question regarding scoping: does the next statement inherit the scope of
the catch block like this?
try {
$user = $repository->findById(123);
$user->setName($name);
2013/4/28 Julien Pauli
> On Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard
> wrote:
>
> > 2013/4/27 Ferenc Kovacs
> >
> >> 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
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 e
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 :
>
> * *
> *
> *try {*
> * foo();*
> * bar();*
> * baz();*
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 Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard wrote:
> 2013/4/27 Ferenc Kovacs
>
>> 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
] Continued try blocks
2013/4/27 Daniel Macedo
> 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
2013/4/27 Daniel Macedo
> 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 afte
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
excepti
2013/4/27 Ferenc Kovacs
> 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 is reached
> 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 feature(alb
2013/4/26 Andreas Heigl
> 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 member
Freitag, 26. April 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 a
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 :
>
> * *
> *
> *try {*
> * foo();*
> * bar();*
> * baz();*
> *} catch (So
Hi
2013/4/26 Lazare Inepologlou :
> 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 i
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
call.
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, i
2013/4/26 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 :
>
> * *
> *
> *try {*
> * foo();*
> * bar();*
> * baz();*
> *} catch (SomeException $e) {*
Sounds interesting. And what about the second attempt passing the try block
without goto?
2013/4/26 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 :
>
>
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 :
*
33 matches
Mail list logo
