{"action":"created","issue":{"url":"https://api.github.com/repos/jasongilman/proto-repl/issues/141","repository_url":"https://api.github.com/repos/jasongilman/proto-repl","labels_url":"https://api.github.com/repos/jasongilman/proto-repl/issues/141/labels{/name}","comments_url":"https://api.github.com/repos/jasongilman/proto-repl/issues/141/comments","events_url":"https://api.github.com/repos/jasongilman/proto-repl/issues/141/events","html_url":"https://github.com/jasongilman/proto-repl/issues/141","id":171063400,"number":141,"title":"handling exceptions","user":{"login":"carocad","id":10408729,"avatar_url":"https://avatars.githubusercontent.com/u/10408729?v=3","gravatar_id":"","url":"https://api.github.com/users/carocad","html_url":"https://github.com/carocad","followers_url":"https://api.github.com/users/carocad/followers","following_url":"https://api.github.com/users/carocad/following{/other_user}","gists_url":"https://api.github.com/users/carocad/gists{/gist_id}","starred_url":"https://api.github.com/users/carocad/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/carocad/subscriptions","organizations_url":"https://api.github.com/users/carocad/orgs","repos_url":"https://api.github.com/users/carocad/repos","events_url":"https://api.github.com/users/carocad/events{/privacy}","received_events_url":"https://api.github.com/users/carocad/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2016-08-14T15:14:03Z","updated_at":"2016-08-30T10:53:57Z","closed_at":null,"body":"Hi jason,\r\nI was taking a look at what we would need to do to make handling of exceptions possible in proto-repl and here are the points that I think are necessary to implement such behaviour.\r\n\r\n- [x] join all stderr messages that we get from the nrepl (see [code](https://github.com/jasongilman/proto-repl/blob/master/lib/process/nrepl-connection.coffee#L162-L166))* (commit 0945a370647d9658bcbe610dd9c5386ce019cb85)\r\n- [x] redirect stderr to only the console and not for inline-results (see [code](https://github.com/jasongilman/proto-repl/blob/master/lib/repl.coffee#L200))** (commit 908d1a0fb2081a1ce24ced83540f68260c4de55b)\r\n- exception widget\r\n  - [x] create an html/js widget to show exceptions inline (commit ac6b54437481f1ce2cef20f2c6ea3b7b3ffac91a)\r\n  - [x] create an exception regex for (most) Clojure's stacktrace analyzers (clojure.stacktrace, clojure.repl) to identify key parts of it. ***\r\n  - [x] put hyperlinks and highlight the lines on the files related to the error (see [ink-code](https://github.com/JunoLab/atom-julia-client/blob/6c0d31456eb5019d8f5d3d472dee96a92bba0c93/lib/runtime/evaluation.coffee#L68-L77))****\r\n\r\n*_the reason why I decided to display err as stderr and not as an exception message is that I found out that proto-repl uses a truncated err messages. For console.stderr that is ok as they are merely text but if you want to put html/js inside then the truncated messages don't work anymore.\r\n\r\n** try calling (clojure.repl/pst) on an editor (not the console). You will see the editor flicker for a brief moment due to it rendering initialy err as the inline-result and then getting 'nil' as result.value, thus overwriting the previous value.\r\n   I guess it is possible to write to stderr without having a real exception so those messages that do not match should probably go to console.stderr directly\r\n\r\n*** There are several ways to display stacktraces in Clojure so supporting all of them if probably too much initially but at least clojure.repl | stacktrace should be enough to begin with.\r\n\r\n**** I'm not completely sure if the highlighting + file-hyperlink would work directly on the console, but I see no reason to believe otherwise.\r\n\r\nI would appreciate your thoughts on the subject"},"comment":{"url":"https://api.github.com/repos/jasongilman/proto-repl/issues/comments/243403640","html_url":"https://github.com/jasongilman/proto-repl/issues/141#issuecomment-243403640","issue_url":"https://api.github.com/repos/jasongilman/proto-repl/issues/141","id":243403640,"user":{"login":"carocad","id":10408729,"avatar_url":"https://avatars.githubusercontent.com/u/10408729?v=3","gravatar_id":"","url":"https://api.github.com/users/carocad","html_url":"https://github.com/carocad","followers_url":"https://api.github.com/users/carocad/followers","following_url":"https://api.github.com/users/carocad/following{/other_user}","gists_url":"https://api.github.com/users/carocad/gists{/gist_id}","starred_url":"https://api.github.com/users/carocad/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/carocad/subscriptions","organizations_url":"https://api.github.com/users/carocad/orgs","repos_url":"https://api.github.com/users/carocad/repos","events_url":"https://api.github.com/users/carocad/events{/privacy}","received_events_url":"https://api.github.com/users/carocad/received_events","type":"User","site_admin":false},"created_at":"2016-08-30T10:53:57Z","updated_at":"2016-08-30T10:53:57Z","body":"Hi Jason,\r\nI think I should explain a bit the background better since the changes are so many.\r\n\r\nAs I mentioned before I wanted to separate stderr from exceptions and have a symmetric way to handle result; for example if you eval and print something, you get a value back and messages to stdout. So I wanted to extend that logic to errors. Eval something that fails, get an exception back and messages to stderr.\r\n\r\nThat was my initial thought, but when I did that I found out that lots of other things were failing due to some ResultHandler() functions expecting result.error, that's when I decided to almost switch things back but since the messages from the repl already contain all the information necessary for us to process it I thought it would be simpler to simply pass the message back instead of creating new objects that copy/past the information that we need.\r\n\r\nNow to your questions:\r\n\r\n1. The purpose of value.coffee is to render anything that will displayed on an editor. I didn't want to use the word Result to avoid confusion with ink's result and with a 'correct' result. \"Value\" is arguably not a good name either as I actually import it as 'Renderer' on the repl.coffee file:https://github.com/jasongilman/proto-repl/compare/master...carocad:exception-handling#diff-55de1e9e7ce745ded36b006d65a27a0bR4.\r\nNone of the code is copied from ink though. The main idea of value.coffee is precisely to simplify and encapsulate all inline-result related functionality. That's the reason why I moved recurseTree to value.coffee. There were so many special/particular conditions for exceptions that I thought that it would be better to avoid having that code on the repl.\r\nI actually decided to use atom-ink's tree view instead of proto-repl precisely to allow some refactor of the treeView code on proto-repl without interfeering with that of exceptions.\r\n\r\n2. Yes definitely. I will do that\r\n\r\n3. I wanted to have all result related functionality at a simple logical place. As I said, 'value' is probably not the best name but I think that the loading widget is more related to inline-results rendering that to proto-repl.coffee, repl.coffee and so on. This change is actually not related to the exception handling so I could revert it if you want.\r\n\r\n4. I wanted to simplify the way that the resultHandler() and handleConnectionMessage() get their values and since the messages from the repl already contain specific keys (err, out, value & ex) that convey their meaning I thought it would be better to return the already existing messages instead of creating yet another object with a custom key.\r\nBefore both handleConnectionMessage() and resultHandler() used different keys for errors: connectionMessage() used result.err whereas resultHandler() used result.error which was quite confusing for me at the beginning. Since both functions are now used at the connection.send() command I thought it would be clearer."}}
{"actor":{"display_login":"carocad"}}