Pathom exceptions have huge ex-message, causing editor lag #142
Comments
|
Seems to be a bad default from the JDK. It means, that this A possible path to solve it: swap this ex-info with a |
|
Impl:
|
|
Hello @nivekuil , what editor do you use? I have received reports on that for people using Emacs, because cider made a decision to always print the full ex-data, is this the same case or something else? |
|
same case, it's still a little laggy with the huge error buffer but substantially better with souenzzo's patch. |
|
I think having |
|
I'm considering adding an option to elide it, the thing is, the reason |
|
Have you had many concrete needs for |
|
Would love to have the option to elide putting the entire env in the ex-data of the exception, or at least put env under one key, e.g. |
|
@aiba in what scenario you see env as the root of ex-data? it shouldn't be as top level anywhere, can you make a repro? |
|
Sure, maybe this makes it more clear: (def temperatures
{"Recife" 23})
(pco/defresolver temperature-from-city [{:keys [city]}]
(throw (ex-info "An intentional error" {:a 1 :b 2}))
{:temperature (get temperatures city)})
(def env (merge (pci/register [temperature-from-city])
{:my-stuff/other-env-key "stuff"}))
(try
(p.eql/process env {:city "Recife"} [:temperature])
(catch Exception ex
(keys (ex-data ex))))when the resolver throws an exception, the caller to :com.wsscode.pathom3.connect.runner/processor-error?
:com.wsscode.pathom3.connect.runner/batch-pending*
:com.wsscode.pathom3.connect.indexes/index-oir
:com.wsscode.pathom3.connect.indexes/index-resolvers
:com.wsscode.pathom3.error/error-data
:com.wsscode.pathom3.entity-tree/entity-tree*
:com.wsscode.pathom3.connect.runner/batch-waiting*
:com.wsscode.pathom3.connect.planner/graph
:com.wsscode.pathom3.connect.runner/root-query
:com.wsscode.pathom3.connect.indexes/index-attributes
:com.wsscode.pathom3.connect.runner/resolver-cache*
:com.wsscode.pathom3.connect.indexes/index-io
:com.wsscode.pathom3.connect.runner/node-run-stats*
:com.wsscode.pathom3.path/path
:com.wsscode.pathom3.connect.planner/plan-cache*
:com.wsscode.pathom3.error/error-message
:com.wsscode.pathom3.connect.runner/graph-run-start-ms
:com.wsscode.pathom3.entity-tree/entity-tree
:com.wsscode.pathom3.error/error-stack)
:my-stuff/other-env-keyAnd this is super cumbersome to log to the console because of all the keys, many of which have values that are themeslves deeply nested maps with many keys. |
|
My current workaround is to wrap process and ditch the ex-data (defn update-ex-data [^ExceptionInfo ex, f]
(let [^Throwable t (ex-info (.getMessage ex)
(f (ex-data ex))
(when-let [cause (.getCause ex)]
(update-ex-data cause f)))]
(.setStackTrace t (.getStackTrace ex))
t))
(defn process [env & args]
(try
(apply p.eql/process env args)
(catch ExceptionInfo ex
(throw (update-ex-data ex (fn [data]
;; ditch all the ex-data for now
{})))))) |
This prints a huge error message. Looking at x, we see it is a string with a value way too big to ever be sensible for ex-message. In fact I had to trim it down or github wouldn't let me post it:
The text was updated successfully, but these errors were encountered: