@ajs, @jeremys, @xiongtx, @noisesmith, and @sundarj: Thanks for tips. I’ll do some reading and look into those.

Is there a way to make emacs not pop open an error buffer when a symbol can’t be resolved?

There's an #emacs channel that may help -- but late on a Saturday evening it's pretty quiet across everywhere here...

@moogey when I used emacs I found an alternative solution - since so many things in emacs create new buffers either replacing or splitting the buffers I'd carefully arranged, I found it useful to use winner-mode, which comes with emacs, and lets you use a keybinding to navigate a "history" of window layouts - which I found easier than customizing or limiting my use of every single function that messed with my layout

alright... so defrecord has me thinking... as I understand it the syntax goes like

(defrecord Name [<argvec>]
     PROTOCOL-1
       (method-1 [this & args} ...)
       (method-2 [this & args] ...)
     PROTOCOL-2
       (method-1 [this & args} ...)
       (method-2 [this & args] ...))

what's the reason for needing to enumerate protocols and you can't just throw in random methods?

is it like an efficiency mechanic or something going on under the hood?

@goomba check out https://clojure.org/reference/protocols

and also https://clojure.org/reference/datatypes, specifically the section “Datatypes and protocols are opinionated”

Good lord that's an elegant explanation

Wasn't ready for that 😅

welcome to Clojure! 🙂

no kidding! I've been doing Clojure for almost six months now but I may as well print out "welcome to Clojure! :)" and make it a sticker along the top of my monitor

haha yeah, it’s (mostly) a happy place

Friday I was getting so frustrated with Clojure I wanted to throw it out the window but by the Grace of Rich and all the wonderful people around here they helped me improve my code so that it smoked my Python code... was so happy

I can relate to that, it takes a long time to adjust but once you get into the groove you really start seeing the benefits 😄

mhm. It's a shame there's not a more straightforward "education" involved with Clojure. Not that it's a bad thing learning like a wizard exploring ancient ruins for arcane scrolls of knowledge

so i'm thinking about how to handle errors in some parts of my code

my initial instinct is to do it erlang-style, where my function returns a tuple with a keyword saying it succeeded/failed and the value if applicable

is this idiomatic clojure? if so, would I return a vector, or a set, or...?

there are many different ways and opinions on how to do that

here’s a library that does exactly what you describe: https://github.com/adambard/failjure

i was looking at that - i just wasn't clear if that was considered within the realm of normal

failjure seems to advocate returning bare values or a failure type, as opposed to always returning a wrapped value

i'm currently thinking of returning e.g. [:ok answer] or [:error "You entered wrong info"]

check this out: https://adambard.com/blog/acceptable-error-handling-in-clojure/

the comments has some gopd info

i'll check it out, thanks!

the either monad from funcool/cats is also worth checking out, that's what I ended up using when thinking about error handling a while back

@lilactown No, it's not idiomatic at all. The standard way is to use try/catch with ex-info. That said, there are many other ways, like people mentioned. You have monadic, condition systems, supervisor style, C style error handling. All can be achieved with Clojure, but non of them I'd consider idiomatic or standard, and will all suffer for poor portability.

also, the implementation of clojure and the underlying vm means your code will need to deal with exceptions (on jvm clojure at least...) - so anything else you implement needs to be a parallel system that won't always apply