You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by "Edinson E. Padrón Urdaneta" <ed...@gmail.com> on 2015/09/28 05:20:48 UTC
Is it possible to implement in the language an `else` block in
exception handling?
This way we could write the following list of 'constructs':
- try-catch-else-finally
- try-catch-else
- try-else-finally
- try-else (I'm not so sure about this one, it could be in conflict with
java(?))
This will improves the readability of exception handling in some
situations. What do you guys think about it?
Thanks in advance for your time.
Cheers.
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by "Edinson E. Padrón Urdaneta" <ed...@gmail.com>.
Hi, Jochen.
The following is part of a previous email I send to this thread addressing
the same concern:
>what would happen if the code that throws the exception is part of a return
>sentence? What if the 'else code' that is after the code that throws the
>exception throws one of its own and it's captured by the catch block(s)? In
>the other hand, isn't more clear to have inside the try block only the code
>that should be 'tested for an exceptional situation'?
Cheers.
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by Matt Quackenbush <qu...@gmail.com>.
Finally *always* runs. Else runs *only if* there are no exceptions.
On Oct 1, 2015 12:08 AM, "Jochen Theodorou" <bl...@gmx.org> wrote:
> Am 28.09.2015 19:44, schrieb Edinson E. Padrón Urdaneta:
>
>> >What behaviour do you expect of the else block if an exception exception
>>
>>> in the try block is thrown, which is not catched and if a finally block
>>> is present? Example:
>>>
>>> try {
>>>> m1() //throws MyException
>>>> } catch (SomeExceptionThatWillNotBeThrown e) {
>>>> } else {
>>>> m2()
>>>> } finally {
>>>> m3()
>>>> }
>>>>
>>>
>>> So is this supposed to do m1();m3() then? In other words apiece of code
>>> executed only if he try block throws no exception at all?
>>>
>>
>> Hi, Jochen. That's right, /m2()/ would not be executed because the
>> exception threw wasn't catch and the normal java/groovy behavior of
>> executing /m3()/ and passing the exception threw inside the try block to
>> the 'next higger context' would happen.
>>
>
>
> sorry, didn't see the answer for some reason... how does it differ from
>
> try {
> m1() // throws MyException
> m2()
> } catch (SomeExceptionThatWillNotBeThrown e) {
> } finally {
> m3()
> }
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/
>
>
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 28.09.2015 19:44, schrieb Edinson E. Padrón Urdaneta:
> >What behaviour do you expect of the else block if an exception exception
>>in the try block is thrown, which is not catched and if a finally block
>>is present? Example:
>>
>>> try {
>>> m1() //throws MyException
>>> } catch (SomeExceptionThatWillNotBeThrown e) {
>>> } else {
>>> m2()
>>> } finally {
>>> m3()
>>> }
>>
>>So is this supposed to do m1();m3() then? In other words apiece of code
>>executed only if he try block throws no exception at all?
>
> Hi, Jochen. That's right, /m2()/ would not be executed because the
> exception threw wasn't catch and the normal java/groovy behavior of
> executing /m3()/ and passing the exception threw inside the try block to
> the 'next higger context' would happen.
sorry, didn't see the answer for some reason... how does it differ from
try {
m1() // throws MyException
m2()
} catch (SomeExceptionThatWillNotBeThrown e) {
} finally {
m3()
}
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by "Edinson E. Padrón Urdaneta" <ed...@gmail.com>.
Well... I think this thread has rested enough. Do you like the
idea/feature/behavior? What should I do next?
On Mon, Sep 28, 2015 at 1:47 PM, Matt Quackenbush <qu...@gmail.com>
wrote:
> I rather like this behavior/feature, which I'm familiar with from Python
> <http://stackoverflow.com/a/16138864>.
>
> On Mon, Sep 28, 2015 at 12:44 PM, Edinson E. Padrón Urdaneta <
> edinson.padron.urdaneta@gmail.com> wrote:
>
>> >What behaviour do you expect of the else block if an exception exception
>> >in the try block is thrown, which is not catched and if a finally block
>> >is present? Example:
>> >
>> >> try {
>> >> m1() //throws MyException
>> >> } catch (SomeExceptionThatWillNotBeThrown e) {
>> >> } else {
>> >> m2()
>> >> } finally {
>> >> m3()
>> >> }
>> >
>> >So is this supposed to do m1();m3() then? In other words apiece of code
>> >executed only if he try block throws no exception at all?
>>
>> Hi, Jochen. That's right, *m2()* would not be executed because the
>> exception threw wasn't catch and the normal java/groovy behavior of
>> executing *m3()* and passing the exception threw inside the try block to
>> the 'next higger context' would happen.
>>
>
>
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by Matt Quackenbush <qu...@gmail.com>.
I rather like this behavior/feature, which I'm familiar with from Python
<http://stackoverflow.com/a/16138864>.
On Mon, Sep 28, 2015 at 12:44 PM, Edinson E. Padrón Urdaneta <
edinson.padron.urdaneta@gmail.com> wrote:
> >What behaviour do you expect of the else block if an exception exception
> >in the try block is thrown, which is not catched and if a finally block
> >is present? Example:
> >
> >> try {
> >> m1() //throws MyException
> >> } catch (SomeExceptionThatWillNotBeThrown e) {
> >> } else {
> >> m2()
> >> } finally {
> >> m3()
> >> }
> >
> >So is this supposed to do m1();m3() then? In other words apiece of code
> >executed only if he try block throws no exception at all?
>
> Hi, Jochen. That's right, *m2()* would not be executed because the
> exception threw wasn't catch and the normal java/groovy behavior of
> executing *m3()* and passing the exception threw inside the try block to
> the 'next higger context' would happen.
>
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by "Edinson E. Padrón Urdaneta" <ed...@gmail.com>.
>What behaviour do you expect of the else block if an exception exception
>in the try block is thrown, which is not catched and if a finally block
>is present? Example:
>
>> try {
>> m1() //throws MyException
>> } catch (SomeExceptionThatWillNotBeThrown e) {
>> } else {
>> m2()
>> } finally {
>> m3()
>> }
>
>So is this supposed to do m1();m3() then? In other words apiece of code
>executed only if he try block throws no exception at all?
Hi, Jochen. That's right, *m2()* would not be executed because the
exception threw wasn't catch and the normal java/groovy behavior of
executing *m3()* and passing the exception threw inside the try block to
the 'next higger context' would happen.
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by Jochen Theodorou <bl...@gmx.org>.
What behaviour do you expect of the else block if an exception exception
in the try block is thrown, which is not catched and if a finally block
is present? Example:
> try {
> m1() //throws MyException
> } catch (SomeExceptionThatWillNotBeThrown e) {
> } else {
> m2()
> } finally {
> m3()
> }
So is this supposed to do m1();m3() then? In other words apiece of code
executed only if he try block throws no exception at all?
bye blackdrag
Am 28.09.2015 18:55, schrieb Edinson E. Padrón Urdaneta:
> Hi, everyone. Thank you for your replays.
>
>> If I understand you correctly, what you're proposing would look a bit like this:
>>
>> try {
>> mayThrow()
>> } catch (e) {
>> handleException(e)
>> } else {
>> try {
>> shouldNotThrowButOneNeverKnows()
>> } catch(e) {
>> handleExceptionInElse(e)
>> }
>> } finally {
>> cleanup()
>> }
>
> That's absolutely correct.
>
>> I have two questions:
>>
>> * `else` as a keyword implies that the `else` block is executed
>> instead of another code block. What would that another block be?
>
> Actually, it would be *blocks*, because the `else` block would be executed
> instead of any `catch` block.
>
>> * if `try` block is the last one in a method, it'll be evaluated as an
>> expression and the result of the last expression inside try/catch is
>> the method's return value. What would be the return value in your
>> proposal?
>
> I'll address this one with the following example:
>
> def specialDivision(Integer a, Integer b) {
> try {
> a / b
> } catch (NullPointerException e) {
> "you didn't initialize correctly one of the arguments"
> } catch (ArithmeticException e) {
> "you can't divide by zero"
> } else {
> "everything went ok"
> }
> }
>
> assert specialDivision(10, null) == "you didn't initialize correctly one
> of the arguments"
> assert specialDivision(10, 0) == "you can't divide by zero"
> assert specialDivision(10, 2) == "everything went ok"
>
> I know this is a silly and very unpractical IRL example but I hope it shows
> the idea I'm proposing. As you can see, the return value is the last
> expression
> of the `else` block if and only if none of the `catch` blocks were executed.
>
> A more general example for further clarification:
>
> try {
> // code that may throw exceptions
>
> } catch (Exception1 e) {
> // code executed if an exception of type Exception1 was throw
> } catch (Exception2 e) {
> // code executed if an exception of type Exception2 was throw
> .
> .
> .
> } catch (ExceptionN e) {
> // code executed if an exception of type ExceptionN was throw
> } else {
> // code executed if none of the above `catch` blocks were executed
> (aka the
> // code inside the try block didn't throw a exception at all)
> } finally {
> // code that is always executed
> }
>
> Someone in SO suggested the following to simulate this behaviour:
>
> def success = true
>
> try {
> // code that may throw exceptions
>
> } catch (Exception1 e) {
> success = false
> // code executed if an exception of type Exception1 was throw
> } catch (Exception2 e) {
> success = false
> // code executed if an exception of type Exception2 was throw
> .
> .
> .
> } catch (ExceptionN e) {
> success = false
> // code executed if an exception of type ExceptionN was throw
> } finally {
> // code that is always executed
> }
>
> if (success) {
> // code executed if none of the above catch blocks were executed (aka the
> // code inside the try block didn't throw a exception at all)
> }
>
> Even if this works I think it introduces a lot of visual noise to the code.
> It's also error prone, you can forget to set the flag `success` to false
> inside
> one or more `catch` blocks. If you use a `return` statement inside the `try`
> block the `if` block at the end will never be executed.
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by "Edinson E. Padrón Urdaneta" <ed...@gmail.com>.
Hi, everyone. Thank you for your replays.
> If I understand you correctly, what you're proposing would look a bit
like this:
>
> try {
> mayThrow()
> } catch (e) {
> handleException(e)
> } else {
> try {
> shouldNotThrowButOneNeverKnows()
> } catch(e) {
> handleExceptionInElse(e)
> }
> } finally {
> cleanup()
> }
That's absolutely correct.
> I have two questions:
>
> * `else` as a keyword implies that the `else` block is executed
> instead of another code block. What would that another block be?
Actually, it would be *blocks*, because the `else` block would be executed
instead of any `catch` block.
> * if `try` block is the last one in a method, it'll be evaluated as an
> expression and the result of the last expression inside try/catch is
> the method's return value. What would be the return value in your
> proposal?
I'll address this one with the following example:
def specialDivision(Integer a, Integer b) {
try {
a / b
} catch (NullPointerException e) {
"you didn't initialize correctly one of the arguments"
} catch (ArithmeticException e) {
"you can't divide by zero"
} else {
"everything went ok"
}
}
assert specialDivision(10, null) == "you didn't initialize correctly one of
the arguments"
assert specialDivision(10, 0) == "you can't divide by zero"
assert specialDivision(10, 2) == "everything went ok"
I know this is a silly and very unpractical IRL example but I hope it shows
the idea I'm proposing. As you can see, the return value is the last
expression
of the `else` block if and only if none of the `catch` blocks were executed.
A more general example for further clarification:
try {
// code that may throw exceptions
} catch (Exception1 e) {
// code executed if an exception of type Exception1 was throw
} catch (Exception2 e) {
// code executed if an exception of type Exception2 was throw
.
.
.
} catch (ExceptionN e) {
// code executed if an exception of type ExceptionN was throw
} else {
// code executed if none of the above `catch` blocks were executed (aka
the
// code inside the try block didn't throw a exception at all)
} finally {
// code that is always executed
}
Someone in SO suggested the following to simulate this behaviour:
def success = true
try {
// code that may throw exceptions
} catch (Exception1 e) {
success = false
// code executed if an exception of type Exception1 was throw
} catch (Exception2 e) {
success = false
// code executed if an exception of type Exception2 was throw
.
.
.
} catch (ExceptionN e) {
success = false
// code executed if an exception of type ExceptionN was throw
} finally {
// code that is always executed
}
if (success) {
// code executed if none of the above catch blocks were executed (aka the
// code inside the try block didn't throw a exception at all)
}
Even if this works I think it introduces a lot of visual noise to the code.
It's also error prone, you can forget to set the flag `success` to false
inside
one or more `catch` blocks. If you use a `return` statement inside the `try`
block the `if` block at the end will never be executed.
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by Dinko Srkoč <di...@gmail.com>.
On 28 September 2015 at 11:33, Bob Brown <bo...@transentia.com.au> wrote:
> I SUSPECT that we are heading towards developing “recovery blocks”, which look like:
>
> ---
> ensure acceptance test
> by primary alternate
> else by alternate 2
> .
> .
> else by alternate n
> else error
>
> ---
Oh, I see. That is interesting.
Scala has somewhat similar feature, albeit without acceptance testing
(only handling exceptions):
Try {
mayThrow()
} orElse {
alternative()
} orElse {
alternative2()
} match {
case Success(res) => res
case Failure(e) => handleException(e)
}
This can be implemented in groovy as a library, just as it is done is scala.
Cheers,
Dinko
>
> I think these first appeared sometime around 1965 (they were part of a specialist real-time language called CORAL, I believe…also a variant of Pascal called “Pascal Plus”, if memory serves...).
>
> Not sure that they were successful…I suspect that they required too much from the run-time support infrastructure. Times change and they may be possible with our MUCH faster hardware.
>
> There are lots of learned academic papers discussing how this is A Good Idea…
>
> BOB
>
>
>
>
>
>
> On 28/09/2015 6:59 pm, "Dinko Srkoč" <di...@gmail.com> wrote:
>
>>On 28 September 2015 at 10:22, Edinson E. Padrón Urdaneta
>><ed...@gmail.com> wrote:
>>> On Mon, Sep 28, 2015 at 3:22 AM, Maarten Boekhold <bo...@gmx.com> wrote:
>>>>
>>>> Just put the 'else' code at the end of the try block!
>>>>
>>>> Maarten
>>>
>>>
>>> That's not a satisfactory answer for my question. Besides, what would happen
>>> if the code that throws the exception is part of a return sentence? What if
>>> the 'else code' that is after the code that throws the exception throws one
>>> of its own and it's captured by the catch block(s)? In the other hand, isn't
>>> more clear to have inside the try block only the code that should be 'tested
>>> for an exceptional situation'?
>>
>>If I understand you correctly, what you're proposing would look a bit like this:
>>
>> try {
>> mayThrow()
>> } catch (e) {
>> handleException(e)
>> } else {
>> try {
>> shouldNotThrowButOneNeverKnows()
>> } catch(e) {
>> handleExceptionInElse(e)
>> }
>> } finally {
>> cleanup()
>> }
>>
>>I have two questions:
>>
>>* `else` as a keyword implies that the `else` block is executed
>>instead of another code block. What would that another block be?
>>* if `try` block is the last one in a method, it'll be evaluated as an
>>expression and the result of the last expression inside try/catch is
>>the method's return value. What would be the return value in your
>>proposal?
>>
>>Cheers,
>>Dinko
>
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by Bob Brown <bo...@transentia.com.au>.
I SUSPECT that we are heading towards developing “recovery blocks”, which look like:
---
ensure acceptance test
by primary alternate
else by alternate 2
.
.
else by alternate n
else error
---
I think these first appeared sometime around 1965 (they were part of a specialist real-time language called CORAL, I believe…also a variant of Pascal called “Pascal Plus”, if memory serves...).
Not sure that they were successful…I suspect that they required too much from the run-time support infrastructure. Times change and they may be possible with our MUCH faster hardware.
There are lots of learned academic papers discussing how this is A Good Idea…
BOB
On 28/09/2015 6:59 pm, "Dinko Srkoč" <di...@gmail.com> wrote:
>On 28 September 2015 at 10:22, Edinson E. Padrón Urdaneta
><ed...@gmail.com> wrote:
>> On Mon, Sep 28, 2015 at 3:22 AM, Maarten Boekhold <bo...@gmx.com> wrote:
>>>
>>> Just put the 'else' code at the end of the try block!
>>>
>>> Maarten
>>
>>
>> That's not a satisfactory answer for my question. Besides, what would happen
>> if the code that throws the exception is part of a return sentence? What if
>> the 'else code' that is after the code that throws the exception throws one
>> of its own and it's captured by the catch block(s)? In the other hand, isn't
>> more clear to have inside the try block only the code that should be 'tested
>> for an exceptional situation'?
>
>If I understand you correctly, what you're proposing would look a bit like this:
>
> try {
> mayThrow()
> } catch (e) {
> handleException(e)
> } else {
> try {
> shouldNotThrowButOneNeverKnows()
> } catch(e) {
> handleExceptionInElse(e)
> }
> } finally {
> cleanup()
> }
>
>I have two questions:
>
>* `else` as a keyword implies that the `else` block is executed
>instead of another code block. What would that another block be?
>* if `try` block is the last one in a method, it'll be evaluated as an
>expression and the result of the last expression inside try/catch is
>the method's return value. What would be the return value in your
>proposal?
>
>Cheers,
>Dinko
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by Dinko Srkoč <di...@gmail.com>.
On 28 September 2015 at 10:22, Edinson E. Padrón Urdaneta
<ed...@gmail.com> wrote:
> On Mon, Sep 28, 2015 at 3:22 AM, Maarten Boekhold <bo...@gmx.com> wrote:
>>
>> Just put the 'else' code at the end of the try block!
>>
>> Maarten
>
>
> That's not a satisfactory answer for my question. Besides, what would happen
> if the code that throws the exception is part of a return sentence? What if
> the 'else code' that is after the code that throws the exception throws one
> of its own and it's captured by the catch block(s)? In the other hand, isn't
> more clear to have inside the try block only the code that should be 'tested
> for an exceptional situation'?
If I understand you correctly, what you're proposing would look a bit like this:
try {
mayThrow()
} catch (e) {
handleException(e)
} else {
try {
shouldNotThrowButOneNeverKnows()
} catch(e) {
handleExceptionInElse(e)
}
} finally {
cleanup()
}
I have two questions:
* `else` as a keyword implies that the `else` block is executed
instead of another code block. What would that another block be?
* if `try` block is the last one in a method, it'll be evaluated as an
expression and the result of the last expression inside try/catch is
the method's return value. What would be the return value in your
proposal?
Cheers,
Dinko
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by "Edinson E. Padrón Urdaneta" <ed...@gmail.com>.
On Mon, Sep 28, 2015 at 3:22 AM, Maarten Boekhold <bo...@gmx.com> wrote:
> Just put the 'else' code at the end of the try block!
>
> Maarten
>
That's not a satisfactory answer for my question. Besides, what would
happen if the code that throws the exception is part of a return sentence?
What if the 'else code' that is after the code that throws the exception
throws one of its own and it's captured by the catch block(s)? In the other
hand, isn't more clear to have inside the try block only the code that
should be 'tested for an exceptional situation'?
Re: Is it possible to implement in the language an `else` block in exception handling?
Posted by Maarten Boekhold <bo...@gmx.com>.
Just put the 'else' code at the end of the try block!
Maarten
On 28 September 2015 11:15:22 "Edinson E. Padrón Urdaneta"
<ed...@gmail.com> wrote:
> Hi, Jochen. Actually, the idea with the else block is to place inside
> it code that would be execute if and only if none exception at all was
> thrown inside its corresponding try block. In other words: the else block
> would be useful for code that must be executed if the try block does not
> throw an exception.
>
> I hope I made me a little more clear this time.
> Cheers.
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by "Edinson E. Padrón Urdaneta" <ed...@gmail.com>.
Hi, Jochen. Actually, the idea with the else block is to place inside
it code that would be execute if and only if none exception at all was
thrown inside its corresponding try block. In other words: the else block
would be useful for code that must be executed if the try block does not
throw an exception.
I hope I made me a little more clear this time.
Cheers.
Re: Is it possible to implement in the language an `else` block in
exception handling?
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 28.09.2015 05:20, schrieb Edinson E. Padrón Urdaneta:
> |This way we could write the following list of 'constructs':
> |
> |
> - try-catch-else-finally|
> |- try-catch|-else
> |- try-else-finally|
> ||- try-else (I'm not so sure about this one, it could be in conflict
> with java(?))
> |
> |
> This will improves the readability of exception handling in some
> situations. What do you guys think about it?
what types of exceptions would be catched in the else block? if it is
Exception and subclasses, we have already something. Example:
try {
foo()
} catch (SomeException se) {
// handle SomeException
} catch (e) {
// handle exception which is not a SomeException
}
going to Throwable or Error can be problematic. And the short version of
the catch here also easily allows to still handle the exception itself.
Does this do what you want?
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/