gmane.comp.lang.groovy.jsr

Daniel.Sun | 8 Feb 07:11

Improvement in handling exception


Hi all,

"the Groovy methods will not declare that they throw any checked exceptions
unless you’ve explicitly added the
declaration, even though they might throw checked exceptions at runtime."
quoted from 'Groovy in Action'

I think Groovy should compel programmers to add 'throws XXXException'
explicitly as Java do when defining a method that can throw some exception.

Why do I think it very vital?
For example,
If I define an exception of my own.

class MyException extends Exception {
  MyException(String msg) {
    super(msg)
  }
}

then I instantiate MyException and throw it in myMethod1

def myMethod1() {
  throw new MyException("error root")
}

then I invoke myMethod1 in myMethod2

def myMethod2() {

(Continue reading)

headers

John Wilson | 8 Feb 08:21

Re: Improvement in handling exception


On 8 Feb 2007, at 06:11, Daniel.Sun wrote:

> Hi all,
>
> "the Groovy methods will not declare that they throw any checked  
> exceptions
> unless you’ve explicitly added the
> declaration, even though they might throw checked exceptions at  
> runtime."
> quoted from 'Groovy in Action'
>
> I think Groovy should compel programmers to add 'throws XXXException'
> explicitly as Java do when defining a method that can throw some  
> exception.
>
> Why do I think it very vital?
> For example,
> If I define an exception of my own.
>
> class MyException extends Exception {
>   MyException(String msg) {
>     super(msg)
>   }
> }
>
> then I instantiate MyException and throw it in myMethod1
>
> def myMethod1() {
>   throw new MyException("error root")

(Continue reading)

headers

Daniel.Sun | 8 Feb 10:23

Re: Improvement in handling exception


Thank you for your patient response.
Maybe I program in Java for a long time, so something groovy I can't
understand and meet troubles half-way :)

John Wilson wrote:
> 
> 
> On 8 Feb 2007, at 06:11, Daniel.Sun wrote:
> 
>> Hi all,
>>
>> "the Groovy methods will not declare that they throw any checked  
>> exceptions
>> unless you’ve explicitly added the
>> declaration, even though they might throw checked exceptions at  
>> runtime."
>> quoted from 'Groovy in Action'
>>
>> I think Groovy should compel programmers to add 'throws XXXException'
>> explicitly as Java do when defining a method that can throw some  
>> exception.
>>
>> Why do I think it very vital?
>> For example,
>> If I define an exception of my own.
>>
>> class MyException extends Exception {
>>   MyException(String msg) {
>>     super(msg)

(Continue reading)

headers

John Wilson | 8 Feb 10:54

Re: Improvement in handling exception


On 8 Feb 2007, at 09:23, Daniel.Sun wrote:

> Thank you for your patient response.
> Maybe I program in Java for a long time, so something groovy I can't
> understand and meet troubles half-way :)

it's no problem:)

I always have a period when moving from programming language X to  
programming language Y of saying "In X we do this why can't I do it  
in Y?". In the end I understnad Y's way of doing things!

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

headers

Daniel.Sun | 8 Feb 11:06

Re: Improvement in handling exception


Yeah, you're right. 
I will take more time in studying Groovy which is really very wonderful
programming language. 
I love it very much :)

John Wilson wrote:
> 
> 
> On 8 Feb 2007, at 09:23, Daniel.Sun wrote:
> 
>> Thank you for your patient response.
>> Maybe I program in Java for a long time, so something groovy I can't
>> understand and meet troubles half-way :)
> 
> 
> it's no problem:)
> 
> I always have a period when moving from programming language X to  
> programming language Y of saying "In X we do this why can't I do it  
> in Y?". In the end I understnad Y's way of doing things!
> 
> 
> John Wilson
> The Wilson Partnership
> web http://www.wilson.co.uk
> blog http://eek.ook.org
> 
> 
>

(Continue reading)

headers

Russel Winder | 8 Feb 11:44

Re: Improvement in handling exception

On Thu, 2007-02-08 at 09:54 +0000, John Wilson wrote:

> I always have a period when moving from programming language X to  
> programming language Y of saying "In X we do this why can't I do it  
> in Y?". In the end I understnad Y's way of doing things!

Back to Marion's thesis 

Don't forget though the situation:

I am moving from language X to language Y, I do this thing this way in X
why can't I do it this way in Y.  Ah you do it that way in Y, but isn't
that ludicrous?  If I did it this way in Y learning a lesson from the
way it is done in X then doesn't that work even better in Y?  Oh yes.

This is why I like working in multiple languages at all times, the
cross-fertilization of idioms makes for much better programs in all
languages.

--

-- 
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             russel@...

headers

Paul King | 8 Feb 11:34

Re: Improvement in handling exception

John Wilson wrote:
> 
> On 8 Feb 2007, at 06:11, Daniel.Sun wrote:
>> [...] I think Groovy should compel programmers to add 'throws XXXException'
>> explicitly as Java do when defining a method that can throw some 
>> exception.
> 
> The debate about checked vs unchecked exceptions is very old. Java has 
> checked exceptions (put into the language at the very last minute), C# 
> does not. There have been many discussions about the robustness of C# 
> applications vs Java ones due to this difference. In practice there 
> seems not to be any difference.

I would present the issues in a different (and much less succinct)
way than John but reach very similar conclusions...

There are those that despise checked exceptions (it makes TDD harder
in Java) and those that argue the benefits. The balanced view for Java
is that checked exceptions should be used when you can reasonably expect
that the caller can and wants/needs to be able to respond to an error
situation. The implication of this is that for nearly any general purpose
library checked exceptions are not usually the way to go because you
can't (in general) always know that a user of your library wants to
respond to your errors. There are many places in Java which don't obey
this rule. Groovy's design choices makes using such classes have much
less scaffolding code and makes various kinds of testing both possible
and relatively easy. You can add the relevant try/catch code if you
wish.

Now, arguments for using checked exceptions within your application

(Continue reading)

headers

Russel Winder | 8 Feb 11:56

Re: Improvement in handling exception

I very much agree with Paul's comments, but I would take a stronger
line:

I think that checked exceptions thrown by library / infrastructure are a
mechanism for the library / infrastructure implementer to control the
way in which an application is to be programmed, i.e. to limit the
freedom of the application developer to design and implement the
application as they want to do.

I find the fascism of checked exceptions issued by libraries /
infrastructure to be extremely constraining -- and if you see any of my
C++ or Java code you will see I am a huge fan of massive static type
checking, and use of cosnt/final everywhere to ensure single assignment
semantics wherever possible (arguably I overdo it .

Personally I can see no use for checked exceptions except where the
throwing and catching are always entirely within the code I write.

On Thu, 2007-02-08 at 20:34 +1000, Paul King wrote:

> There are those that despise checked exceptions (it makes TDD harder
> in Java) and those that argue the benefits. The balanced view for Java
> is that checked exceptions should be used when you can reasonably expect
> that the caller can and wants/needs to be able to respond to an error
> situation. The implication of this is that for nearly any general purpose
> library checked exceptions are not usually the way to go because you
> can't (in general) always know that a user of your library wants to
> respond to your errors. There are many places in Java which don't obey
> this rule. Groovy's design choices makes using such classes have much
> less scaffolding code and makes various kinds of testing both possible

(Continue reading)

headers

Jochen Theodorou | 8 Feb 13:15

Re: Improvement in handling exception

John Wilson schrieb:
[...]
> I do, however, think that  we could improve our Exception handling whit 
> respect to Java interfacing. If a groovy method throws a checked 
> exception but does not have a throws clause then a Java method which 
> calls it cannot catch the exception.

a reason to declare that Exception in the throws clause

> The Groovy compiler can tell that a 
> checked exception is thrown and could, in principle, put the throws 
> clause into the generated bytecode.

sure yes... when I move the exception throwing code into another method, 
then what? I don't think we should do that... too much magic and for 
APIwriters it is a bad thing to have these Exceptions in there without 
their knowledge. And if I write a method m1 that calls a method m2 that 
throws a checked exception e1 and if I call this method m1, then how do 
I catch e1? When I think about IOEceptions, then I think it is not 
reasonable to automatically put anything into the method signature, that 
is not decided by the programer.

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------

(Continue reading)