Argh going round in circles - what is this error?

Hiya,

Happy new year to all.

I'm trying to run some Groovy unit tests in IntelliJ IDEA using the  
plugin, and this used to work... but now no matter what test case I  
run I get:

Caught: UNCAUGHT EXCEPTION: null

That's all it says in the output. Not very helpful. No trace :(

I can run scripts OK, its just test cases -that rely on another  
class- that won't. Even if I empty out those other classes used by  
the test, so there is only a trivial static test { println "test" }  
method in them, it still has this error. Its some weird classloader/ 
path problem :(

Any ideas?

~ ~ ~
Marc Palmer (marc@...)
Consultant/Analyst
AnyWare Ltd.
http://www.anyware.co.uk/

IllegalMonitorState exception with synchronized

Hi,

Am I doing something wrong? I get IllegalMonitorStateException in  
this code:

class PollSubmissionHandler extends EmailSubmissionHandler
{
     private static Map pollCache = new HashMap()

     static List getCachedPollResults( DataSource ds, String pollID)
     {
         synchronized (pollCache)
         {
             def cache = pollCache[pollID]
             if (cache == null)
             {
                 def results = Polls.getPollResults( ds, pollID)
                 if (results != null)
                 {
                     cache = results
                     pollCache[pollID] = results
                 }
             }
             return cache // Throws exception here according to trace
         }
     }
}

If I remove the synchronized block this code works fine. I'm not sure  

Hello and thanks

Hi Marc,

I'm one of the many people reading your posts on groovy-user. Just 
wanted to say thanks for reporting problems as you go and for raising 
detailed bug reports in JIRA. Groovy has a long way to go, but users 
like you are making sure it gets there faster.

Alan.

PS: wangjammer5? Ouch!

Re: Hello and thanks

On 2 Jan 2006, at 23:40, Alan Green wrote:

>
>
> Hi Marc,
>
> I'm one of the many people reading your posts on groovy-user. Just  
> wanted to say thanks for reporting problems as you go and for  
> raising detailed bug reports in JIRA. Groovy has a long way to go,  
> but users like you are making sure it gets there faster.
>

That's decent of you but really... its the developers who deserve  
thanks. Without it I would have no bugs to report, and no cool  
scripting language!

Debugging scripts is however extremely painful at the moment. I've  
just had a very tough day chasing mysterious messages.

The GREAT news is that this project is finally launching tomorrow,  
the first working day of 2006. TIP: Never let a client talk you into  
a product launch at the start of the new year, it wrecks your  
holidays :(

Once it is live I will provide the URL. It's nothing that impressive  
but it is quite a high profile UK food product's web site built with  
Groovy, so that has to be good!

> PS: wangjammer5? Ouch!

switch and if/then give unexpected results with BigDecimal

Re: switch and if/then give unexpected results with BigDecimal

Scott Hickey schrieb:

>  
> 
> Testing for 1 == 1.0 and BigDecimal("1") == BigDecimal("1.0") produce 
> different results in the if statement versus the case statement. I'm not sure 
> what the intended behavior is. My gut reaction is that for scripting language, 1 
> == 1.0 and 1.0 == 1.00 should always be true.
> 
> Below is a script that illustrates the behavior. In either case, I 
> think most users would expect the switch and if statements to behave the same. Any 
> thoughts on this?

currently only the equals method of BigDecimal is used. But in terms of 
this equals methode, 1.0 and 1.00 are not equal. This means we have to 
write our own equals-method here. Any suggestions?

bye blackdrag

Re: switch and if/then give unexpected results with BigDecimal

On 3 Jan 2006, at 14:57, Scott Hickey wrote:

> Testing for 1 == 1.0 and BigDecimal("1") == BigDecimal("1.0") produce
> different results in the if statement versus the case statement.  
> I'm not sure
> what the intended behavior is. My gut reaction is that for  
> scripting language, 1
> == 1.0 and 1.0 == 1.00 should always be true.
>
> Below is a script that illustrates the behavior. In either case, I
> think most users would expect the switch and if statements to  
> behave the same. Any
> thoughts on this?

We appear to be using compareTo in conditionals and equals in  
switches. This doesn't make any difference for most things but  
produces the behaviour you observe for BigDecimal.

import java.math.BigDecimal

def oneBD = new BigDecimal("1") // 1 with scale zero

println oneBD.equals(1)
println oneBD.equals(1.0)
println oneBD.compareTo(1)
println oneBD.compareTo(1.0)

produces

false
false
0
0

I'm not a BD expert but it looks like a bug to me.

John Wilson
The Wilson Partnership
http://www.wilson.co.uk

Re: switch and if/then give unexpected results with BigDecimal

Re: switch and if/then give unexpected results with BigDecimal

On 3 Jan 2006, at 16:09, Scott Hickey wrote:

> So compare must also be what's used in the following as well?
>
> Version: 1.0-jsr-04-SNAPSHOT JVM: 1.4.2_08-b03
> Type 'exit' to terminate the shell
> Type 'help' for command help
> Type 'go' to execute the statements
>
> groovy> println 1.0 == 1.00
> groovy> go
> true

Yes, compareTo is used fro ==. <, >, => etc

John Wilson
The Wilson Partnership
http://www.wilson.co.uk

ResultSet from stored procedure call() method