Clojure

Exceptions thrown in the top level ns form are reported without file or line number

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Completed
  • Affects Version/s: Release 1.3, Release 1.4, Release 1.5, Release 1.6
  • Fix Version/s: Release 1.6
  • Component/s: None
  • Labels:
  • Patch:
    Code
  • Approval:
    Ok

Description

If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

(ns clj14.myns
  (:use
   [clojure.core :only seq]))

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

Exception :only/:refer value must be a sequential collection of symbols  clojure.core/refer (core.clj:3854)

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

Patch: clj-939-v4.diff

Approach: The latest patch does not modify the behavior of any other exceptions thrown by the compiler. The throw-if function is only used in the load-related functions: this patch changes it to throw CompilerException instead of Exception. As a result, exceptions which occur while loading files will be decorated with file names and line/column numbers. The line/column numbers are not always accurate (see notes in attachment screen-clj-939.org) but the file names are correct.

This is an incremental improvement to compile-time error messages, but it does not solve some of the fundamental problems with reporting correct line/column numbers from errors thrown by the compiler.

Screened by: Stuart Sierra (re-screened by Alex for the specific comments by Rich)

Activity

Hugo Duncan made changes -
Field Original Value New Value
Attachment 0002-report-load-exceptions-with-file-and-line.diff [ 10968 ]
Rich Hickey made changes -
Fix Version/s Release 1.5 [ 10150 ]
Andy Fingerhut made changes -
Stuart Sierra made changes -
Waiting On richhickey
Approval Screened [ 10004 ]
Rich Hickey made changes -
Fix Version/s Release 1.5 [ 10150 ]
Rich Hickey made changes -
Approval Screened [ 10004 ] Incomplete [ 10006 ]
Alex Miller made changes -
Approval Incomplete [ 10006 ] Triaged [ 10120 ]
Andy Fingerhut made changes -
Description If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

This generates a {{Don't know how to create ISeq from: clojure.lang.Symbol}} exception, with source file or line number.
If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v2.txt

*Approach*:

Question from Rich in comment: This patch doesn't change the reporting on any other (e.g. nested) exceptions? It looks like it might.

At least a partial answer: This patch wraps some exceptions in a CompilerException, with the cause as the original exception. Method analyzeSeq in Compiler.java has a very similar throw new CompilerException(...) statement that wraps any Throwable that is not a CompilerException into a CompilerException. One difference is that in analyzeSeq, it explicitly avoids wrapping a CompilerException inside of another CompilerException.

The attachment file out-1.6.0-unmodified.txt gives some sample output for attempts to require two trivial namespaces with errors in them, and shows the exceptions raised. Attachment file out-1.6.0-clj-939-patch.txt gives the corresponding output after this patch was applied.
Affects Version/s Release 1.6 [ 10157 ]
Affects Version/s Release 1.5 [ 10150 ]
Andy Fingerhut made changes -
Attachment out-1.6.0-clj-939-patch.txt [ 12201 ]
Attachment out-1.6.0-unmodified.txt [ 12200 ]
Andy Fingerhut made changes -
Description If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v2.txt

*Approach*:

Question from Rich in comment: This patch doesn't change the reporting on any other (e.g. nested) exceptions? It looks like it might.

At least a partial answer: This patch wraps some exceptions in a CompilerException, with the cause as the original exception. Method analyzeSeq in Compiler.java has a very similar throw new CompilerException(...) statement that wraps any Throwable that is not a CompilerException into a CompilerException. One difference is that in analyzeSeq, it explicitly avoids wrapping a CompilerException inside of another CompilerException.

The attachment file out-1.6.0-unmodified.txt gives some sample output for attempts to require two trivial namespaces with errors in them, and shows the exceptions raised. Attachment file out-1.6.0-clj-939-patch.txt gives the corresponding output after this patch was applied.
If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v2.txt

*Approach*:

Question from Rich in comment: This patch doesn't change the reporting on any other (e.g. nested) exceptions? It looks like it might.

At least a partial answer: This patch wraps some exceptions in a new CompilerException, with the original exception as the new one's cause. Method analyzeSeq in Compiler.java has a very similar "throw new CompilerException(...)" statement that wraps any Throwable that is not a CompilerException into a new CompilerException. One difference is that in analyzeSeq, it propagates CompilerExceptions without wrapping them in a new one.

The attachment file out-1.6.0-unmodified.txt gives some sample output for attempts to require two trivial namespaces with errors in them, and shows the exceptions raised. Attachment file out-1.6.0-clj-939-patch.txt gives the corresponding output after this patch was applied.
Andy Fingerhut made changes -
Andy Fingerhut made changes -
Description If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v2.txt

*Approach*:

Question from Rich in comment: This patch doesn't change the reporting on any other (e.g. nested) exceptions? It looks like it might.

At least a partial answer: This patch wraps some exceptions in a new CompilerException, with the original exception as the new one's cause. Method analyzeSeq in Compiler.java has a very similar "throw new CompilerException(...)" statement that wraps any Throwable that is not a CompilerException into a new CompilerException. One difference is that in analyzeSeq, it propagates CompilerExceptions without wrapping them in a new one.

The attachment file out-1.6.0-unmodified.txt gives some sample output for attempts to require two trivial namespaces with errors in them, and shows the exceptions raised. Attachment file out-1.6.0-clj-939-patch.txt gives the corresponding output after this patch was applied.
If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v3.txt

*Approach*:

Question from Rich in comment: This patch doesn't change the reporting on any other (e.g. nested) exceptions? It looks like it might.

At least a partial answer: Rich's question was written when the current patch was clj-939-report-load-exceptions-with-file-and-line-patch-v2.txt (note the -v2). That patch always wrapped any exception caught in method load() in a CompilerException, even if it was a CompilerException. Most other places in Compiler.java that throw CompilerExceptions make an explicit check to avoid doing this.

Patch clj-939-report-load-exceptions-with-file-and-line-patch-v3.txt (note the -v3) adds this explicit check. Unfortunately that change by itself still means that the line and column numbers of exceptions thrown by require/use/load-lib are always 1:1. Patch v3 also changes throw-if to throw a CompilerException, which makes the line and column numbers those of the beginning of the enclosing ns form, if there is one.

The only case I know of where the line/column number are off with this patch (seems to always be 1:1) is if the require/use is for a non-existent namespace. The filename is still correct, and the nonexistent namespace name is given in the exception message as before.
Andy Fingerhut made changes -
Attachment out-1.6.0-clj-939-patch.txt [ 12201 ]
Andy Fingerhut made changes -
Attachment out-1.6.0-unmodified.txt [ 12200 ]
Alex Miller made changes -
Labels errormsgs
Rich Hickey made changes -
Approval Triaged [ 10120 ] Vetted [ 10003 ]
Fix Version/s Release 1.6 [ 10157 ]
Stuart Sierra made changes -
Assignee Stuart Sierra [ stuart.sierra ]
Stuart Sierra made changes -
Approval Vetted [ 10003 ] Screened [ 10004 ]
Description If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v3.txt

*Approach*:

Question from Rich in comment: This patch doesn't change the reporting on any other (e.g. nested) exceptions? It looks like it might.

At least a partial answer: Rich's question was written when the current patch was clj-939-report-load-exceptions-with-file-and-line-patch-v2.txt (note the -v2). That patch always wrapped any exception caught in method load() in a CompilerException, even if it was a CompilerException. Most other places in Compiler.java that throw CompilerExceptions make an explicit check to avoid doing this.

Patch clj-939-report-load-exceptions-with-file-and-line-patch-v3.txt (note the -v3) adds this explicit check. Unfortunately that change by itself still means that the line and column numbers of exceptions thrown by require/use/load-lib are always 1:1. Patch v3 also changes throw-if to throw a CompilerException, which makes the line and column numbers those of the beginning of the enclosing ns form, if there is one.

The only case I know of where the line/column number are off with this patch (seems to always be 1:1) is if the require/use is for a non-existent namespace. The filename is still correct, and the nonexistent namespace name is given in the exception message as before.
If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v3.txt

*Approach*: The latest patch does not modify the behavior of any other exceptions thrown by the compiler. The {{throw-if}} function is only used in the load-related functions: this patch changes it to throw {{CompilerException}} instead of {{Exception}}. As a result, exceptions which occur while loading files will be decorated with file names and line/column numbers. The line/column numbers are not always accurate (see notes in attachment {{screen-clj-939.org}}) but the file names are correct.

This is an incremental improvement to compile-time error messages, but it does not solve some of the fundamental problems with reporting correct line/column numbers from errors thrown by the compiler.
Attachment screen-clj-939.org [ 12282 ]
Assignee Stuart Sierra [ stuart.sierra ]
Alex Miller made changes -
Description If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v3.txt

*Approach*: The latest patch does not modify the behavior of any other exceptions thrown by the compiler. The {{throw-if}} function is only used in the load-related functions: this patch changes it to throw {{CompilerException}} instead of {{Exception}}. As a result, exceptions which occur while loading files will be decorated with file names and line/column numbers. The line/column numbers are not always accurate (see notes in attachment {{screen-clj-939.org}}) but the file names are correct.

This is an incremental improvement to compile-time error messages, but it does not solve some of the fundamental problems with reporting correct line/column numbers from errors thrown by the compiler.
If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v3.txt

*Approach*: The latest patch does not modify the behavior of any other exceptions thrown by the compiler. The {{throw-if}} function is only used in the load-related functions: this patch changes it to throw {{CompilerException}} instead of {{Exception}}. As a result, exceptions which occur while loading files will be decorated with file names and line/column numbers. The line/column numbers are not always accurate (see notes in attachment {{screen-clj-939.org}}) but the file names are correct.

This is an incremental improvement to compile-time error messages, but it does not solve some of the fundamental problems with reporting correct line/column numbers from errors thrown by the compiler.

*Screened by:* Stuart Sierra
Alex Miller made changes -
Description If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v3.txt

*Approach*: The latest patch does not modify the behavior of any other exceptions thrown by the compiler. The {{throw-if}} function is only used in the load-related functions: this patch changes it to throw {{CompilerException}} instead of {{Exception}}. As a result, exceptions which occur while loading files will be decorated with file names and line/column numbers. The line/column numbers are not always accurate (see notes in attachment {{screen-clj-939.org}}) but the file names are correct.

This is an incremental improvement to compile-time error messages, but it does not solve some of the fundamental problems with reporting correct line/column numbers from errors thrown by the compiler.

*Screened by:* Stuart Sierra
If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v3.diff

*Approach*: The latest patch does not modify the behavior of any other exceptions thrown by the compiler. The {{throw-if}} function is only used in the load-related functions: this patch changes it to throw {{CompilerException}} instead of {{Exception}}. As a result, exceptions which occur while loading files will be decorated with file names and line/column numbers. The line/column numbers are not always accurate (see notes in attachment {{screen-clj-939.org}}) but the file names are correct.

This is an incremental improvement to compile-time error messages, but it does not solve some of the fundamental problems with reporting correct line/column numbers from errors thrown by the compiler.

*Screened by:* Stuart Sierra
Attachment clj-939-report-load-exceptions-with-file-and-line-patch-v3.diff [ 12360 ]
Rich Hickey made changes -
Approval Screened [ 10004 ] Incomplete [ 10006 ]
Andy Fingerhut made changes -
Attachment clj-939-v4.diff [ 12395 ]
Andy Fingerhut made changes -
Attachment clj-939-v4.diff [ 12395 ]
Andy Fingerhut made changes -
Attachment clj-939-v4.diff [ 12397 ]
Alex Miller made changes -
Waiting On richhickey
Approval Incomplete [ 10006 ] Screened [ 10004 ]
Description If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-report-load-exceptions-with-file-and-line-patch-v3.diff

*Approach*: The latest patch does not modify the behavior of any other exceptions thrown by the compiler. The {{throw-if}} function is only used in the load-related functions: this patch changes it to throw {{CompilerException}} instead of {{Exception}}. As a result, exceptions which occur while loading files will be decorated with file names and line/column numbers. The line/column numbers are not always accurate (see notes in attachment {{screen-clj-939.org}}) but the file names are correct.

This is an incremental improvement to compile-time error messages, but it does not solve some of the fundamental problems with reporting correct line/column numbers from errors thrown by the compiler.

*Screened by:* Stuart Sierra
If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

{code}
(ns clj14.myns
  (:use
   [clojure.core :only seq]))
{code}

With the latest Clojure master as of Aug 24 2013, this generates the following exception, with no source file or line number except the one shown in clojure.core:

{code}
Exception :only/:refer value must be a sequential collection of symbols clojure.core/refer (core.clj:3854)
{code}

You can find a source file in your project if you painstakingly search through the stack trace, but it would be nice if it jumped out at you in the exception itself.

*Patch*: clj-939-v4.diff

*Approach*: The latest patch does not modify the behavior of any other exceptions thrown by the compiler. The {{throw-if}} function is only used in the load-related functions: this patch changes it to throw {{CompilerException}} instead of {{Exception}}. As a result, exceptions which occur while loading files will be decorated with file names and line/column numbers. The line/column numbers are not always accurate (see notes in attachment {{screen-clj-939.org}}) but the file names are correct.

This is an incremental improvement to compile-time error messages, but it does not solve some of the fundamental problems with reporting correct line/column numbers from errors thrown by the compiler.

*Screened by:* Stuart Sierra (re-screened by Alex for the specific comments by Rich)
Rich Hickey made changes -
Approval Screened [ 10004 ] Ok [ 10007 ]
Stuart Halloway made changes -
Resolution Completed [ 1 ]
Status Open [ 1 ] Closed [ 6 ]

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: