Question: assuming you knew that the ret value was the form of an exception, then if you get one of those, it failed and maybe it is needed and we’ll find that and it will change I’m not trying to be a pain about this, really just trying to push against adding more stuff if it’s not actually needed maybe relevant to have a predicate to ask: does this map represent an exception? in all of these cases (exception during read, exception during eval, return value is an exception), a repl does the same thing: it prints the exception I’m not sure that it’s relevant whether it failed during read or evaluation

Asked By
Asked At
2018-02-09 19:32:40

Found 15 possible answers.

User Answered At Possible Answer
gfredericks 2018-02-09 21:52:37 as a user I think it's important for me to be shown the difference between a thrown and returned exception; I disagree that repls do the same thing in either case (just print the exception), though that might be true for the most basic repl
seancorfield 2018-02-09 21:53:12 @gfredericks glad I'm not the only one :slightly_smiling_face:
gfredericks 2018-02-09 21:55:08 e.g., currently I use cider and it pops up another buffer when an exception is thrown, which is rather jarring in a way that seems sort of appropriate (even if I might prefer it slightly differently, like printed in red in the repl buffer) I think I've programmed before it contexts where you can't tell the difference, and have found myself having to write try/catch code that wraps things just so I can figure out what's going on if I eval something that returns an exception, I'd want it to calmly print data like it does for anything else
bhauman 2018-02-09 22:00:28 the current clojure,main/repl-caught provides different behavior when its a thrown exception and benefits from the differentiation
alexmiller 2018-02-09 22:01:34 true, although I think when we circled back to look at it during the socket repl, we regretted that :)
gfredericks 2018-02-09 22:02:59 what was regrettable?
alexmiller 2018-02-09 22:05:02 that it did something different, and also, what it did :) we went a ways down a path on changing that but eventually undid most of it. but that path is where Throwable->map showed up
gfredericks 2018-02-09 22:05:46 is it just a "more code than necessary" problem, or does doing something different make something else more difficult? users can opt-out of the distinction, can't they?
alexmiller 2018-02-09 22:07:45 less is more I actually haven’t talked to Rich about this (yet) but clearly he made a conscious choice here
seancorfield 2018-02-09 22:30:12 Thinking about this some more, I guess tools _can_ tell the difference between a successful eval and one that threw -- and even whether read failed:
{:tag :ret ; could be exception from read, exception from eval, or result
:ns ...} ; always present
It feels a bit hinky to check for :ms and :form to determine what :val is but doable. Although I would want some assurances from @alexmiller (or Rich!) that those keys would not "change" in terms of being there or not. :ms ... ; only present if eval succeeded :form ... ; only present if read succeeded :val ... ; Throwable->map or result
bhauman 2018-02-09 22:39:02 well that is enough for me thanks for pointing that out
cgrand 2018-02-10 01:46:32 Clever
thheller 2018-02-21 08:36:04 @alexmiller jira spam at it again
alexmiller 2018-02-21 13:15:16 Got it, thanks
thheller 2018-02-21 18:04:01 @alexmiller did you miss the second one?

Related Questions