groovy

Groovy swallowing exceptions when MissingMethodException occurs with a closure that throws an exception

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Cannot Reproduce
  • Affects Version/s: 1.6.3
  • Fix Version/s: 1.6.4, 1.7-beta-1
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

The following code when run in Groovy console produces no output whatsoever:

interface Callback {
   def execute();
}

def test(Callback callable) {
     println "crap"
}

test({ throw new Exception("ugly")} as Callback, true)

The reason is the logic that formulates the message for the MissingMethodException is invoking the passed closure resulting in the exception contained within the closure being thrown and the original root cause being swallowed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Graeme Rocher added a comment -

Just to add I have no idea why Groovy is invoking user defined closures passed as arguments to the method when constructing the MissingMethodException but it seems like a completely braindead idea to me. Groovy should never invoke user defined code in the construction of error messages that could potentially consume other errors.

Show
Graeme Rocher added a comment - Just to add I have no idea why Groovy is invoking user defined closures passed as arguments to the method when constructing the MissingMethodException but it seems like a completely braindead idea to me. Groovy should never invoke user defined code in the construction of error messages that could potentially consume other errors.
Hide
Permalink
blackdrag blackdrag added a comment -

what should the error message then be?

Show
blackdrag blackdrag added a comment - what should the error message then be?
Hide
Permalink
blackdrag blackdrag added a comment -

as for executing user defined code. Groovy executed toString() here. In case of Closures this lead to the execution of the closure, but in theory any object can have a toString() method that has side effects or other bad effects. One way would be to still execute toString, but to catch the exception and then do something useful. Or to not to execute toString() and write something else.. which would be?

Show
blackdrag blackdrag added a comment - as for executing user defined code. Groovy executed toString() here. In case of Closures this lead to the execution of the closure, but in theory any object can have a toString() method that has side effects or other bad effects. One way would be to still execute toString, but to catch the exception and then do something useful. Or to not to execute toString() and write something else.. which would be?
Hide
Permalink
blackdrag blackdrag added a comment -

looks like I cannot reproduce the bug anymore. Closure has no toString() method, meaning unless some code (like in GString) is converting the Closure into a Writable nothing bad will happen

Show
blackdrag blackdrag added a comment - looks like I cannot reproduce the bug anymore. Closure has no toString() method, meaning unless some code (like in GString) is converting the Closure into a Writable nothing bad will happen

People

  • Assignee:
    blackdrag blackdrag
    Reporter:
    Graeme Rocher
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: