Clojurians Log v2
clojurescript 2025-04-23
This seems like a bug to me? Using limit in string/split gives the wrong result on a simple split.
In clojurescript
(clojure.string/split "a|b" #"|")
;=> ["a" "|" "b"]
(clojure.string/split "a|b" #"|" 3)
;=> ["" "" "a|b"]Corresponding js code
"a|b".split(/|/)
;=> ['a', '|', 'b']
"a|b".split(/|/, 3)
;=> ['a', '|', 'b']
Seems utterly wrong, yes. Same with passing 2 - well, at least Clojure behaves differently.
Can you create a post on http://ask.clojure.org about it?
Oh, the pipe needs to be escaped?
When it's not escaped, the RegEx is still valid, and the result should be different.
Yes... I'm confused. string/split "a|b" #"\|" 2) gives ["a" "b"] which is what one would expect.
I've added a bit to the Ask post.
What does #"|" even mean? 馃槃 I meant to split on | with a limit and was confused by the result and did not notice that "|" was included in the result without the limit.
"An empty string or an empty string", I think.
Aha...
Not sure why it doesn't result in "" when there's no limit though, but #"" does.
Hi! I'm working with ClojureScript + shadow-cljs + core.async + nodejs stack and stumbled upon unexpected behavior of core.async exception handling. Reduced my problem to following code:
(go
(try
(let [failing-channel (go (throw (js/Error. "Forced error for (.on js/process "uncaughtException"
(fn [err]
(js/console.error "Unhandled exception in worker:" err)))
this is all working as intended. node by default just dies on any uncaught exception. the throw in the inner go is never caught anywhere. the outer try/catch is out of scope for that.
Thank you! I had wrong expectations that it's designed as monad(similar to async/await). Now I get the idea. Funny that it was never a problem unti I decided to create better logging for errors
Do you also see this error message in the console?
Unhandled exception in worker: ....uncaughtException event handler, which is the anonymous fn that just consumes it (and does not rethrows).Yes, I see this message if "uncaughtException" is set. If it is not set - nodejs process just instantly killed and no "catch" block is fired
ok, that means digging in cljs source code including core.async/go to see if there is any code that is throwing exception but not being handled thus causing node process emitting the uncaughtException event. Hope you get to the bottom of that
I may be misunderstanding your question, but I think that's expected. There's no default mechanism for handling errors thrown inside go/thread blocks. <! won't throw, it will just return nil. There are a few libs that implement some error handling on top of core async, but in the past I just used simple macros like this: https://gist.github.com/vvvvalvalval/f1250cec76d3719a8343#file-aynchronous-errors-clj-L4-L32