Clojure

Error messages for invalid destructured bindings are not helpful

Details

  • Type: Enhancement Enhancement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Declined
  • Affects Version/s: Release 1.3
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

Errors in destructured forms throw errors that give no clue to what the actual problem is. For example, evaluating (let [[a b] 3] a) throws a 'nth not supported on type Long' error. It is not obvious that the destructuring expression is at fault.

There should be another exception at the top level in the stack trace, something along the lines of of "DestructuringException: value <value> could not be destructured", with the 'nth not supported' exception as its cause.

Activity

Luke VanderHart made changes -
Field Original Value New Value
Assignee Luke VanderHart [ lvanderhart ]
Luke VanderHart made changes -
Attachment 742.diff [ 10117 ]
Luke VanderHart made changes -
Status Open [ 1 ] In Progress [ 3 ]
Luke VanderHart made changes -
Status In Progress [ 3 ] Open [ 1 ]
Luke VanderHart made changes -
Patch Code
Luke VanderHart made changes -
Attachment 742.diff [ 10117 ]
Luke VanderHart made changes -
Patch Code
Hide
Luke VanderHart added a comment -

This may not be possible. Destructuring is implemented as a macro-like transformation on the expressions - by the time the expressions are evaluated and an error occurs, the runtime has no way of knowing that the expression was once destructured.

Tagging the expressions with some sort of flag to indicate they were destructured is unviable. Not only is is complicated, it has runtime performance penalties.

Show
Luke VanderHart added a comment - This may not be possible. Destructuring is implemented as a macro-like transformation on the expressions - by the time the expressions are evaluated and an error occurs, the runtime has no way of knowing that the expression was once destructured. Tagging the expressions with some sort of flag to indicate they were destructured is unviable. Not only is is complicated, it has runtime performance penalties.
Luke VanderHart made changes -
Description Errors in destructured forms throw errors that give no clue to what the actual problem is. For example, evaluating (let [[a b] 3] a) throws a 'nth not supported on type Long' error. It is not obvious that the destructuring expression is at fault.

There should be another exception at the top level in the stack trace, something along the lines of of "DestructuringException: value <value> could not be destructured", with the 'nth not supported' exception as its cause. There shouldn't be any significant performance impact to catching and re-throwing any Exception thrown during evaluation of a destructuring expression.
Errors in destructured forms throw errors that give no clue to what the actual problem is. For example, evaluating (let [[a b] 3] a) throws a 'nth not supported on type Long' error. It is not obvious that the destructuring expression is at fault.

There should be another exception at the top level in the stack trace, something along the lines of of "DestructuringException: value <value> could not be destructured", with the 'nth not supported' exception as its cause.
Hide
Stuart Halloway added a comment -

I don't see a way to do this without runtime implications, even in the no-error case. I guess the destructure macro could emit special variants destructuring-nth and destructuring-get, etc. that provide specaliazed error messages...

Show
Stuart Halloway added a comment - I don't see a way to do this without runtime implications, even in the no-error case. I guess the destructure macro could emit special variants destructuring-nth and destructuring-get, etc. that provide specaliazed error messages...
Stuart Halloway made changes -
Issue Type Defect [ 1 ] Enhancement [ 4 ]
Stuart Halloway made changes -
Status Open [ 1 ] Resolved [ 5 ]
Resolution Declined [ 2 ]
Stuart Halloway made changes -
Status Resolved [ 5 ] Closed [ 6 ]

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: