-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
With catch-app-errors, an error below das:http-request is silently captured #12
Comments
So by virtue of the fact that you're using a library which plugs into the futures "platform," you have to be a bit mindful of errors. What's happening here is Here's how you'd catch errors when futures are involved: (defun test-case ()
(as:with-event-loop (:catch-app-errors t)
(future-handler-case
(attach (das:http-request "http://iki.fi/") #'test-error)
(t (e) (format t "err: ~a~%" e))))) So future-handler-case acts like In your case, the actual error would be some sort of argument mismatch: the callback given to |
Thank you. (defun print-error (e)
(format t "err: ~a~%" e))
(defun test-case ()
(as:with-event-loop (:catch-app-errors t :default-event-cb #'print-error)
(asf:future-handler-case
(asf:attach (das:http-request "http://iki.fi/") #'test-error)))) |
Ok, it took me a bit but I figured this out. What's happening is that Meanwhile,
(handler-case
(error caught-error)
[handler forms...]) Because you don't have any handler forms, the error (rethrown inside the So while it all gets confusing, I think this is working as intended (and probably as best as it can be built). The docs might be confusing here, I probably need to update the section on error handling to make this all a bit clearer. Please let me know if you have any questions or suggestions or anything. |
After a little bit of practice, with proper handling of all errors, it feels pleasant to use your libraries. Actually, I'm building a replacement for the good old CL GitHub feed (http://planet.lisp.org/github.atom), which became defunct due to changes in GitHub. Now my worker is catching up on the repositories created since then. (GitHub API provides only for exhaustive scan of all repositories for the info on the language; there is a Web search query which returns the right number of repositories so far, but has its own drawbacks: https://github.com/search?l=Common+Lisp&q=%22%22.) I noticed two oddities in the libraries. First, as:event-error does not inherit from error. Second, asf lacks its version of as:delay: (defmacro asf:delay ((&key time) &body body)
(with-gensyms (future)
`(let ((,future (asf:make-future)))
(as:delay (lambda () (asf:finish ,future (progn ,@body))) :time ,time)
,future))) |
Thanks, I'm glad you like the libs! So are you scraping that github search page? Scraping and crawling is one place async stuff really shines. Are you replacing the old CL github feed or will there be a new URL posted once you're done? I'm interested to know your progress! Also, I think the fact that As far as the delay macro, yeah it's a pretty common pattern. I have done this countless times myself =]. However because it's not providing direct futures functionality (and also because it ties the futures implementation to cl-async too closely since right now they can both be run completely independent from each other) it will most likely be kept out. |
Oh, with futures being a subsection in the cl-async documentation, and being named cl-async-futures, I did not notice they were in fact independent from cl-async. The section "Integration with cl-async" explains why futures are not integrated into cl-async, i.e. why cl-async is not implemented in terms of futures; not why they are not integrated with cl-async. However, I see some beauty in this independence. I subscribed to the issue you opened; I think you meant to title it "Extend event-error class from error". No, GitHub API is a dedicated service, separate from their HTML frontend. I'm scraping https://api.github.com/repositories and then individual repository pages. This amounts to ~700 000 requests to catch up with GitHub since the last entry of CL GitHub. GitHub allows everyone 5 000 requests per hour, so the whole process takes 6 days, and I'm 4 days in. Obviously, scraping the search page would be less resource intensive, but I already had an implementation using GitHub API (synchronously) for a corporate GitHub, and I did not remember the way to trick search system intro returning all repositories for a particular language until the previous reply here. And as a benefit, I have data on all the languages. Most of them have traffic lower or around that of Common Lisp, which marks them as targets as suitable to follow. Whether to replace the old feed will be for Zach to decide, but I am certain to give some options as to what to subscribe for elsewhere too. |
Just to let you know, so far I have twice encountered |
The cl-async/cl-async-future docs need to be split up, but I am too lazy/busy to do it for a bit. Futures used to be a part of cl-async, but I got a few requests to split them up because the futures could conceivably be used in any async system, not just cl-async. Instead of moving the docs, I just left them and liked to them from cl-async-future's README =]. Thanks for the rundown feed, interesting stuff. |
Can you open a separate issue for that in cl-async? Also, any details you can give (how many outbound reqs you're doing, 32bit/64bit, SBCL version, etc) would be really helpful. |
I am not sure whether the problem is in das, asf, or my code, but it seems wrong that this finishes without error:
The text was updated successfully, but these errors were encountered: