NPE while getting candidates about compliment HOT 9 CLOSED

I thought the exceptions from Compliment are handled, as per #35. CC: @bbatsov

from compliment.

I thought the exceptions from Compliment are handled, as per #35. CC: @bbatsov

They are - you get a stracktrace in your REPL buffer. :-) Obviously it'd be better if the users weren't exposed to any such errors.

from compliment.

So, as I already told in #35, it's no problem for me to wrap every API function in generic try/catch. But then, by silently swallowing all exceptions, I leave no options for user library (like cider-nrepl) to handle it differently. I think the try/catch block should wrap completions and documentation on cider-nrepl side, not Compliment side.

from compliment.

I think the try/catch block should wrap completions and documentation on cider-nrepl side, not Compliment side.

I think we all agree on this. It just hasn't been done yet.

from compliment.

I'm not saying we should swallow exceptions in compiment - I'm saying we should handle expected problems gracefully - e.g. I don't think anyone should expect a NPE from java.util.concurrent.ConcurrentHashMap.get. Compliment might raise some more specific exception and cider can handle it.

from compliment.

OK, agreed.

Looking at the stacktrace I can tell that this happens when candidates function of ns-mappings source gets null as ns argument. But the top-level completions should never pass a null namespace to the underlying functions. I'll need a reproducible case to weed out this bug.

from compliment.

I don't have time to investigate further. My biggest gripe was that I was prevented from typing when each keypress changed focus to the repl so I could look at the stacktrace.

from compliment.

No need to close this yet. Someone might bump into this issue and have more insights.

from compliment.

I suppose the issue is probably fixed now. Compliment doesn't seem to throw this exception anymore, and CIDER has a exception muffling mechanism. Closing.

from compliment.