Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Continue analysing other namespaces after a failure #57

Open
danielcompton opened this issue Aug 22, 2022 · 2 comments
Open

Continue analysing other namespaces after a failure #57

danielcompton opened this issue Aug 22, 2022 · 2 comments

Comments

@danielcompton
Copy link

I noticed shadow-cljs imports were failing. Looking at a recent build, I could see the error was:

Execution error (ClassNotFoundException) at java.net.URLClassLoader/findClass (URLClassLoader.java:476).\norg.graalvm.polyglot.PolyglotException$StackFrame\n",
  :clojure.main/triage
  {:clojure.error/class java.lang.ClassNotFoundException,
   :clojure.error/line 476,
   :clojure.error/cause
   "org.graalvm.polyglot.PolyglotException$StackFrame",
   :clojure.error/symbol java.net.URLClassLoader/findClass,
   :clojure.error/source "URLClassLoader.java",
   :clojure.error/phase :execution},

Even if we can't analyse that one namespace, there are probably other namespaces that could be analysed. It seems like it would be good to have an option to keep analysing other namespaces. At the end of the analysis, cljdoc could still show that there were errors, and in the namespace sidebar show the failed namespace in red.

This would let the rest of the library continue to be analysed, even if one part fails.

I'm not well versed in how this all works, so maybe this isn't possible/a good idea.

@lread
Copy link
Member

lread commented Aug 22, 2022

Hi @danielcompton thanks for raising this issue!

There is something raised around this cljdoc/cljdoc#228.

My guess was that this might get weird/tricky for load-time analysis.
When you analyze ns x it may require nses y and z, then z may include nses c and d.
And d might be the one that fails. Last time I looked, I think it was for cljs, it was a challenge to detect where the failure had occurred.

At one point I was of the opinion that if your code can't load it should fail analysis.
I also felt that we would not be doing devs/readers a favour by including partial API docs.
But maybe that's a bit of a hard stance, I dunno.
Happy to discuss.

Related issues are: cljdoc/cljdoc#565, cljdoc/cljdoc#543 and cljdoc/cljdoc#628

@danielcompton
Copy link
Author

And d might be the one that fails. Last time I looked, I think it was for cljs, it was a challenge to detect where the failure had occurred.

You could still track failures by the entrypoint. If x can't be loaded because of a problem in d, it's still a problem for x.

At one point I was of the opinion that if your code can't load it should fail analysis.

Yeah, I can see it both ways, you might be right about it being confusing if there are only partial docs. People don't always read everything to realise there has been a partial failure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants