Error formatting macro: pagetree: java.lang.NullPointerException
Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

Some Related Problems

Clojure's rich, unified approach to data does not extend to exception types. As a result:

  • error handling is interop, not awesome
    • built-in Java exception types provide one-off APIs
      • can't consume them as data interactively or programmatically
    • people in Clojure add to the mess by making more
    • exception handling still driven by fixed inheritance hierarchy
      • not idiomatic anywhere else in Clojure
  • precompilation of code should not be necessary
    • projects dragged there just for exceptions
  • information is not available when you need it to respond
    • interactive response: want data
      • maps not custom types
    • and more of it
      • locals
      • dynamics
      • the expression that caused the problem

Assumptions / Constraints

  • but the information cannot cost a fortune
    • pay for what you need
    • dynamic selection of error handling features
    • requirement for wrapping not idiomatic in Clojure, and unacceptable
  • Integrate well with platform
  • Work ok (= no worse than Java) for interop callers
  • Exceptions are not for flow control
    • multimethod dispatch speed probably ok
  • Not trying to add conditions today
    • but don't want to make any choices that prohibit them later

Phase One

Provide built-in Clojure exception types that are richer than Java exceptions, and eliminate the need for app developers to gen-class their own exception types. Since some information is costly to provide, provide a *debug* flag that allows the costly stuff to be disabled in production.

Debug Builds

  • the following group of features will be enabled when *debug* is set
    • assert
    • *unchecked-math* math becomes checked math
      • explicit unchecked does not change (might be for semantic reasons)
    • include locals (and bindings ??) in all thrown errors (or in assertions if this is too hard)
      • is conditional in throw path too expensive?
      • otherwise compile throw differently based on flag
  • unify with Java assertions?
  • Need separate assert-like constructs that never get turned off
    • typical name: verify
    • for preconditions: prefix either verify- or assert- to :pre and :post ??
      • what is the default ??

Errors as Data

Provide built-in types than extend a few subclasses Throwable and also provide IPersistentMap. Goal: The new types are capable enough that Clojure programmers can be out of the business of making new Throwable subclasses.

  • expose error info as part of the map
  • clojure owns unnamespaced keywords
  • include :namespace key
    • will be a great match target, alleviate one want for typed exceptions
  • no need to include :fn key
    • not a good match target
    • available for human consumption in context of stacktrace
  • need a few different types
    • error, runtimeexception, assertion?
  • need names
    • unworkable: Clojure, PersistentMap,
    • maybe: Condition (but don't want to suggest non-error flow control)
  • provide fn that parses Java exceptions into similar maps
    • e.g. clj-stacktrace
  • REPL exception help works in terms of maps, not Java exceptions