Fork me on GitHub

@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

Lone Ranger16:07:51

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

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

Lone Ranger16:07:12

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

Lone Ranger16:07:31

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


and also, specifically the section “Datatypes and protocols are opinionated”

Lone Ranger16:07:08

Good lord that's an elegant explanation

Lone Ranger16:07:27

Wasn't ready for that 😅


welcome to Clojure! 🙂

Lone Ranger17:07:13

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

Lone Ranger17:07:28

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 😄

Lone Ranger17:07:58

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:


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"]


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