Re: lazy-cat's memoization obscuring runtime exceptions

On Monday, June 13, 2016 at 4:38:47 PM UTC-4, Gary Trakhman wrote: > > What's surprising about this? Maybe you want the promoting *' variant: > > > (def expexp (lazy-cat [2] (map #(*' % %) expexp))) > #'sandbox21201/expexp > > (take 100 expexp) > Execution Timed Out! > > Seems like it's a big numb

Re: lazy-cat's memoization obscuring runtime exceptions

Ah, sorry I missed that the first time around. There's something similar going on with lazy-seq. user=> (defn the-seq #_=> ([] (the-seq 2)) #_=> ([a] (cons (* a a) (lazy-seq (the-seq (* a a)) user=> (def s (the-seq)) #'user/s user=> (take 100 s) ArithmeticException integer overflow

Re: lazy-cat's memoization obscuring runtime exceptions

What's surprising is that I executed a pure function twice in succession and got different results. Furthermore the second execution papers over an exception. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to cloju

Re: lazy-cat's memoization obscuring runtime exceptions

I'm not aware of a ticket on it, feel free to file one. tryclj dumps your session periodically and you'll lose any vars you've defined. On Monday, June 13, 2016 at 3:27:54 PM UTC-5, Sebastian Oberhoff wrote: > > The following lines are copied straight from tryclj.com > > > (def expexp (lazy-cat

Re: lazy-cat's memoization obscuring runtime exceptions

What's surprising about this? Maybe you want the promoting *' variant: > (def expexp (lazy-cat [2] (map #(*' % %) expexp))) #'sandbox21201/expexp > (take 100 expexp) Execution Timed Out! Seems like it's a big number :-) On Mon, Jun 13, 2016 at 4:27 PM Sebastian Oberhoff < oberhoff.sebast...@gm

lazy-cat's memoization obscuring runtime exceptions

The following lines are copied straight from tryclj.com > (def expexp (lazy-cat [2] (map #(* % %) expexp))) #'sandbox20298/expexp > (take 100 expexp) java.lang.ArithmeticException: integer overflow > (take 100 expexp) (2 4 16 256 65536 4294967296) I'm wondering if this behavior is known, because

Re: [question] lein repl exceptions

Specifically, you want (clojure.repl/pst) This function can also take as an input a number of how deep a stacktrace you want back. I use this when the reported stacktrace is not long enough. On Thu, May 19, 2016 at 8:13 PM, Mars0i wrote: > Try (pst) . > > -- > You received this message because

Re: [question] lein repl exceptions

Beautiful. Thanks. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group,

[question] lein repl exceptions

Try (pst) . -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send em

[question] lein repl exceptions

For some time I've noticed that certain exception are not printing a stacktrace when they occur in 'lein repl'. They just print a oneliner like: ArityException Wrong number of args (3) passed to: my_ns/my_fn/fn--1648 clojure.lang.AFn.throwArity (AFn.java:429) Is there a way to force them t

[ANN] io.aviso/pretty 0.1.21 -- pretty printing of Clojure exceptions

Library for helping print things prettily, in Clojure - ANSI fonts, formatted exceptions This release adds improved docstrings for the ANSI font constants and functions. It understands Clojure's invokePrim() stack frames, and that .cljc sources (from 1.7) are also Clojure. It is now possib

[ANN] io.aviso/pretty 0.1.20 -- pretty printing of Clojure exceptions

Library for helping print things prettily, in Clojure - ANSI fonts, formatted exceptions This release improves Leiningen integration; when Pretty is used as a plugin, it is enabled for both REPL and for tests. Pretty has been updated for Clojure 1.8, specifically, to recognize direct linked

Re: JDBC Rollbacks and Exceptions

Andy Chambers wrote on Thursday, November 12, 2015 at 10:49 PM: I threw up an example repo demonstrating the type of test I'd like to be able to write somehow. Maybe I'm just trying to test something that should be tested in other ways. https://github.com/cddr/jdbc-demo As Andrey indicates, what

Re: JDBC Rollbacks and Exceptions

On Fri, Nov 13, 2015 at 8:49 AM, Andy Chambers wrote: > On Friday, October 30, 2015 at 5:22:40 PM UTC-7, Sean Corfield wrote: >> >> Could you provide a bit more context? >> >> We’re using clojure.java.jdbc very heavily in production and we don’t >> see any pr

Re: JDBC Rollbacks and Exceptions

On Friday, October 30, 2015 at 5:22:40 PM UTC-7, Sean Corfield wrote: > > Could you provide a bit more context? > > We’re using clojure.java.jdbc very heavily in production and we don’t see > any problems with exceptions. > Hi Sean, I threw up an example repo demonstrating th

Re: JDBC Rollbacks and Exceptions

Could you provide a bit more context? We’re using clojure.java.jdbc very heavily in production and we don’t see any problems with exceptions. Sean Andy Chambers wrote on Friday, October 30, 2015 at 3:52 PM: Has anyone found a way to "reset" a connection after a rollback? It seems

JDBC Rollbacks and Exceptions

Hey All, Has anyone found a way to "reset" a connection after a rollback? It seems like after an exception is triggered, the connection cannot be used again, even if you just want to rollback and continue with the next insert. This is a problem if you want to both clean the database state by r

Re: Handling exceptions with Reader Conditionals

ndling: >> >> "Exception handling, catching "all" - see issue below on why this is not >> a complete solution in either case." >> >> I looked further down the page and couldn't see a discussion of why this >> isn't a complete solution

Re: Handling exceptions with Reader Conditionals

elow on why this is not a > complete solution in either case." > > I looked further down the page and couldn't see a discussion of why this > isn't a complete solution. The only mentions of exceptions talked about > them at read time, but not in this context at run time. I

Handling exceptions with Reader Conditionals

oked further down the page and couldn't see a discussion of why this isn't a complete solution. The only mentions of exceptions talked about them at read time, but not in this context at run time. Is this mentioned somewhere, on this page or elsewhere? If it's not mentioned elsewh

Re: What is current "best practice" regarding exceptions?

On a project I worked on we used a bit of a heavy handed method. Our system was rather distributed, where servers processed messages off of durable queues. So we took a simplistic approach: Exceptions that bubbled all the way up to the top level of the application caused a hard exit of the JVM

Re: What is current "best practice" regarding exceptions?

1) no 2) no 3) yes at all cost 4) both, exceptions are logged with context (current bindings, etc) 5) undecided, under close examination however 6) never have to restart, we check what cause the error and correct it externally if required most errors are reported immediately, may depend on

What is current "best practice" regarding exceptions?

I'm curious, how are people in the Clojure community currently dealing with exceptions? I have a diverse set of questions on this topic. 1.) How many have adopted an Erlang "die fast and restart" strategy? 2.) How many use something like Supervisor to spin up new JVMs? If

Re: debugging "MyClass cannot be cast to MyClass" exceptions

:01 PM UTC-8, juan.facorro wrote: >>>>>>> >>>>>>> Hi Brian, >>>>>>> >>>>>>> This problem usually happens when working on the REPL and you >>>>>>> redefine a record or type (derecord and deft

Re: debugging "MyClass cannot be cast to MyClass" exceptions

t;>>> >>>>>> This problem usually happens when working on the REPL and you >>>>>> redefine a record or type (derecord and deftype), but there are still >>>>>> some >>>>>> existing instances lying around, that belong to the previous

Re: debugging "MyClass cannot be cast to MyClass" exceptions

>>>>> a record or type (derecord and deftype), but there are still some >>>>> existing >>>>> instances lying around, that belong to the previous definition of that >>>>> same >>>>> type. >>>>> >>>&

Re: debugging "MyClass cannot be cast to MyClass" exceptions

l some existing >>>> instances lying around, that belong to the previous definition of that >>>> same >>>> type. >>>> >>>> See this thread for more information: https://groups. >>>> google.com/forum/#!msg/clojure/N2ivUM8bvB8/

Re: debugging "MyClass cannot be cast to MyClass" exceptions

>>> google.com/forum/#!msg/clojure/N2ivUM8bvB8/xgiFVtsXKnkJ >>> >>> Cheers, >>> >>> Juan >>> >>> On Saturday, December 6, 2014 5:55:23 PM UTC-3, Brian Craft wrote: >>>> >>>> I'm experimenting with jwrapper, and am gett

Re: debugging "MyClass cannot be cast to MyClass" exceptions

;> >> Cheers, >> >> Juan >> >> On Saturday, December 6, 2014 5:55:23 PM UTC-3, Brian Craft wrote: >>> >>> I'm experimenting with jwrapper, and am getting runtime exceptions like >>> this, due to some jar manipulation that it's doing. I know

Re: debugging "MyClass cannot be cast to MyClass" exceptions

: > https://groups.google.com/forum/#!msg/clojure/N2ivUM8bvB8/xgiFVtsXKnkJ > > Cheers, > > Juan > > On Saturday, December 6, 2014 5:55:23 PM UTC-3, Brian Craft wrote: >> >> I'm experimenting with jwrapper, and am getting runtime exceptions like >> this

Re: debugging "MyClass cannot be cast to MyClass" exceptions

://groups.google.com/forum/#!msg/clojure/N2ivUM8bvB8/xgiFVtsXKnkJ Cheers, Juan On Saturday, December 6, 2014 5:55:23 PM UTC-3, Brian Craft wrote: > > I'm experimenting with jwrapper, and am getting runtime exceptions like > this, due to some jar manipulation that it's doing. I know one

debugging "MyClass cannot be cast to MyClass" exceptions

I'm experimenting with jwrapper, and am getting runtime exceptions like this, due to some jar manipulation that it's doing. I know one of the steps is pack200, however running pack200 manually doesn't create these issues. Anyone have suggestions for debugging this? I've see

Re: unexpected behavior catching exceptions within a go block

st.github.com/yayitswei/d80d51ee29dc5e2c1117 > > How do you handle exceptions when processing items asynchronously from a > queue? > Failing preconditions throw AssertionError, which is not a subclass of Exception. That is why it's not being caught. - Chris -- You received this m

unexpected behavior catching exceptions within a go block

This gist illustrates a problem I'm having where the channel is closed after running into an exception, even if I put a try/catch block around the block that generates the exception: https://gist.github.com/yayitswei/d80d51ee29dc5e2c1117 How do you handle exceptions when processing

Re: stack backtraces for exceptions in agents?

PS I should have said "thanks!". -Lee On Jun 2, 2014, at 3:52 PM, Lee Spector wrote: > > Beautiful. > > In fact, if I specify an :error-handler of: > > (fn [agnt except] (clojure.repl/pst except 1000) (System/exit 0)) > > Then it prints the backtrace and also terminates execution. > > FW

Re: stack backtraces for exceptions in agents?

, 2014, at 3:39 PM, Andy Fingerhut wrote: > Try out (clojure.repl/pst e 1000), where e is the exception you have caught. > > Andy > > > On Mon, Jun 2, 2014 at 12:28 PM, Lee Spector wrote: > > In my single-threaded code, exceptions stop execution and print a stack >

Re: stack backtraces for exceptions in agents?

Try out (clojure.repl/pst e 1000), where e is the exception you have caught. Andy On Mon, Jun 2, 2014 at 12:28 PM, Lee Spector wrote: > > In my single-threaded code, exceptions stop execution and print a stack > backtrace. This is less informative than I would like [1], but som

Re: stack backtraces for exceptions in agents?

(fn [agnt except] (println except)) -Lee On Jun 2, 2014, at 3:38 PM, Sean Corfield wrote: > The exception object should have a full stack trace in it - how are you > printing your exceptions? > > Sean > > On Jun 2, 2014, at 12:28 PM, Lee Spector wrote: >> In

Re: stack backtraces for exceptions in agents?

The exception object should have a full stack trace in it - how are you printing your exceptions? Sean On Jun 2, 2014, at 12:28 PM, Lee Spector wrote: > In my single-threaded code, exceptions stop execution and print a stack > backtrace. This is less informative than I would like [1

stack backtraces for exceptions in agents?

In my single-threaded code, exceptions stop execution and print a stack backtrace. This is less informative than I would like [1], but sometimes it provides crucial clues. My multi-threaded code generally uses agents (just because that's the best way I've found to get something th

Re: problem catching exceptions in webapp

(assert false) throws AssertionError which doesn't extend Exception and therefore is not caught. :: Immo 2014-02-27 13:42 GMT+02:00 Wei Hsu : > I'm having trouble catching exceptions in my Compojure web app. Made a > small test case to illustrate the issue: > https://g

problem catching exceptions in webapp

I'm having trouble catching exceptions in my Compojure web app. Made a small test case to illustrate the issue: https://github.com/yayitswei/exceptiontest Could you take a look and spot what I'm doing wrong? Thanks, Wei -- You received this message because you are subscribed to

Re: clojure.edn/read-string exceptions => nil

Shouldn't that be: (defn filter-printable [obj] (cond (or (symbol? obj) (number? obj) (string? obj) (keyword? obj)) obj (vector? obj) (apply vector (map filter-printable obj)) (seq? obj) (map filter-printable obj) (set? obj) (into #{} (map filter-printable obj)) (map? obj) (into {

Re: clojure.edn/read-string exceptions => nil

I recently ran into this problem again. The solution I came up with is: (defn filter-printable [obj] (cond (or (symbol? obj) (number? obj) (string? obj) (keyword? obj)) obj (vector? obj) (apply vector (map filter-printable obj)) (seq? obj) (map filter-printable obj) (set? obj) (into

Re: clojure.edn/read-string exceptions => nil

After looking at edn/read-string and realizing I would have to modify Java code, I have decided that modifying the sender in clojure land isn't so bad after all. On Thu, Jan 16, 2014 at 9:41 AM, Alex Miller wrote: > I think I would change the sender to elide whatever parts you don't want > to s

Re: clojure.edn/read-string exceptions => nil

I think I would change the sender to elide whatever parts you don't want to send rather than mess with the receiver. On Thursday, January 16, 2014 2:11:02 AM UTC-6, t x wrote: > > Hi, > > Right now if I do (clojure.edn/read-string ...) on a string with a > unreadable part, I get an exception.

Re: clojure.edn/read-string exceptions => nil

ause > > for this specific exception and wrap it in a function for ease > > of use. You might want to throw up any other exceptions and > > only catch this one > > > > Luc P. > > > > > > > I should add: this problem arises due to cljs / clojure tal

Re: clojure.edn/read-string exceptions => nil

4 at 1:47 AM, Luc Prefontaine < > lprefonta...@softaddicts.ca> wrote: > >> Wrap the read in a try catch just return nil in the catch clause >> for this specific exception and wrap it in a function for ease >> of use. You might want to throw up any other exceptions and >>

Re: clojure.edn/read-string exceptions => nil

taine < lprefonta...@softaddicts.ca> wrote: > Wrap the read in a try catch just return nil in the catch clause > for this specific exception and wrap it in a function for ease > of use. You might want to throw up any other exceptions and > only catch this one > > Luc

Re: clojure.edn/read-string exceptions => nil

Wrap the read in a try catch just return nil in the catch clause for this specific exception and wrap it in a function for ease of use. You might want to throw up any other exceptions and only catch this one Luc P. > I should add: this problem arises due to cljs / clojure talking over

Re: clojure.edn/read-string exceptions => nil

I should add: this problem arises due to cljs / clojure talking over the network, so: (*) not using serialization is NOT an option (*) however, I don't have to use edn/read-string + pr-str (*) it's perfectly fine to use different encoding/decoding methods On Thu, Jan 16, 2014 at 12:11 AM, t x

clojure.edn/read-string exceptions => nil

Hi, Right now if I do (clojure.edn/read-string ...) on a string with a unreadable part, I get an exception. Instead, I would like to just get nil. For example: ## code (clojure.edn/read-string (pr-str {:tag :message :chan (async/chan 10)})) ## currently returns java.lang.RuntimeExcept

Re: Catching Exceptions from Threads in REPL

Have you experimented with setting a default uncaught exception handler? See http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler) *Neale Swinnerton* {t: @sw1nn , w: sw1nn.com }

Catching Exceptions from Threads in REPL

I'm working on a multithreaded program, and debugging in the repl is very hard. Every time an exception occurs, the thread either shuts down or deals with it in some other way. Is there a way I can get the REPL to intercept the exception and display it? -- -- You received this message beca

Re: Model validation - exceptions as side-effects?

On 18/08/2013 2:00 PM, "Alexandr Kurilin" wrote: > > I'd love to know your expert opinion on this, since you wrote Bouncer: say > you're in the situation I listed above, where you don't care about nice > error handling, you just want to give the caller a 400 if the input is > incorrect. Would you

Re: Model validation - exceptions as side-effects?

Le 18 août 2013 06:00, "Alexandr Kurilin" a écrit : > > My thought process was that at this point I have a pure API that either gets the right inputs or it simply does nothing. As in, no helping messages about what went wrong, no attempt to do recovery. Some claim that for security purposes errors

Re: Model validation - exceptions as side-effects?

Leonardo, that's an interesting solution, thanks for writing it out and giving me some food for thought. My thought process was that at this point I have a pure API that either gets the right inputs or it simply does nothing. As in, no helping messages about what went wrong, no attempt to do re

Re: Model validation - exceptions as side-effects?

I would prefer not throwing an exception in the case of a validation. Say your validation function returns a vector or the first argument contains validation errors if any and the second contains the original map: (validate my-map) ;; returns [{:errors '("blah")} original-map] Then a neat way t

Model validation - exceptions as side-effects?

Let's hypothetically say I have a Ring application and I'm performing some validation on the input map I receive as part of a POST request. The validate function throws an exception if anything's wrong with the input. The exception is caught in the middleware and turned into a 400 code response

ANN: conditions 0.1.0, a simple resumable exceptions library

Hello all, I'm releasing a small library for using resumable exceptions, aka conditions, in Clojure. Resumable exceptions allow the decision about what kind of response to take to an exception to be made in a separate place (higher up the call stack) from where the actual response itself is

Re: do background threads sometimes swallow exceptions?

loser to the problem. > > Wrap the entire new thread "body" in a try/catch, it should reveal any > exceptions there may be. Also, if you're actually revving up new Threads, this sometimes comes in handy: http://docs.oracle.com/javase/6/docs/api/java/lang/Th

Re: do background threads sometimes swallow exceptions?

>I don't see any threads in your Stack Overflow post. I thought it would be over-complicated to include all of the code. But inside my -main function I start a new thread and call the function that calls the function that causes this error. >They are not "lost". Unhan

do background threads sometimes swallow exceptions?

I think someone on this mailist recently said that an exception that occurs in a thread is sometimes lost? That is, even if I put in a lot of pprint statements or println statements* or (stack/print-stack-trace e) expressions, and I just want it to show up in terminal, so I can debug it, but if

Re: ClojureScript: catching all javascript exceptions

Thanks Steve - exactly what I needed - cool stuff. On Nov 1, 2012, at 3:06 AM, Steve Buikhuizen wrote: > No problem. On the client (cljs) you should: > • require [goog.debug.ErrorReporter :as reporter] > • (reporter/install "/er") > On the server (I'm using Noir which supplies defpa

Re: ClojureScript: catching all javascript exceptions

In past I used (goog.debug.ErrorReporter/install"logError") It worked great. HTH, Hubert. Steve Buikhuizen wrote: No problem. On the client (cljs) you should: 1. require [goog.debug.ErrorReporter :as reporter] 2. (reporter/install"/er") On the server (I'm using Noir which supplies defpage)

Re: ClojureScript: catching all javascript exceptions

No problem. On the client (cljs) you should: 1. require [goog.debug.ErrorReporter :as reporter] 2. (reporter/install "/er") On the server (I'm using Noir which supplies defpage) (defpage [:post "/er"] {:keys [error line script trace]} (service/record-client-error error line script tr

Re: ClojureScript: catching all javascript exceptions

Hi Steve, That sounds very intriguing, but with my limited javascript&goog knowledge it's difficult to see how you would go about it. Could you please elaborate on what you did and how you get those js-errors reported back to a web server as some form of logging-service (?). Thanks, FrankS.

Re: ClojureScript: catching all javascript exceptions

Take a look at http://closure-library.googlecode.com/svn-history/r9/trunk/closure/goog/docs/class_goog_debug_ErrorReporter.html Since all Google Closure is available to clojurescript (in web clients) you can use the static "install" method to log all errors in the client back to the server.

Re: ClojureScript: catching all javascript exceptions

try in clojurescript is actually a macro that uses the builtin try* and adds type dispatch. So to catch everything, just use (try* ... (catch e ...)). This maps directly to javascript's try. This question seems to come up a lot: Maybe it should be documented where it's visible to people looking fo

Re: ClojureScript: catching all javascript exceptions

Very useful example - thanks. This should be explained in the official clojurescript doc pages in the exceptions section. -FS. On Oct 31, 2012, at 3:24 AM, Alexander Solovyov wrote: > On Wed, Oct 31, 2012 at 11:22 AM, AtKaaZ wrote: >> seems to be working here: https://himera.hero

Re: ClojureScript: catching all javascript exceptions

On Wed, Oct 31, 2012 at 11:22 AM, AtKaaZ wrote: > seems to be working here: https://himera.herokuapp.com/index.html > > cljs.user> (try (+ 1 2) (catch js/Error e e)) > 3 > cljs.user> (try (throw (js/Error. "err1")) (catch js/Error e e)) > # This is not working: (try (throw "err1") (catch js/Erro

Re: ClojureScript: catching all javascript exceptions

struct just not >> implemented now. >> >> 在 2012年9月27日星期四UTC+8下午11时08分22秒，Dima B写道： >>> >>> Hi, >>> >>> I came to the point where I need to be able to catch all javascript >>> exceptions, log them down and swallow. I've been trying to a

Re: ClojureScript: catching all javascript exceptions

mented now. > > 在 2012年9月27日星期四UTC+8下午11时08分22秒，Dima B写道： >> >> Hi, >> >> I came to the point where I need to be able to catch all javascript >> exceptions, log them down and swallow. I've been trying to achieve this by >> >> (try .

Re: ClojureScript: catching all javascript exceptions

星期四UTC+8下午11时08分22秒，Dima B写道： > > Hi, > > I came to the point where I need to be able to catch all javascript > exceptions, log them down and swallow. I've been trying to achieve this by > > (try ... (catch Exception e ...)) > (try ... (catch nil e ...)) > (try ... (

Re: Inconsistent Exceptions

Compile compliance level: 1.6 Generated class files compatibility: 1.6 Source compatibility: 1.6 I think regardless of what jdk you use to run/compile them, these 3 (or at least the first 2) are affecting what you said. I got those from eclipse (but there should be command line equivalents of thos

Re: Inconsistent Exceptions

I just found out that my clojure project is using jre7, while the other project is using jre6. That probably has something to do with it. On Monday, 15 October 2012 19:17:26 UTC-4, JvJ wrote: > > I'm having a peculiar issue with Java interop. > > I'm running a program in 2 different ways: > -Run

Inconsistent Exceptions

I'm having a peculiar issue with Java interop. I'm running a program in 2 different ways: -Running the program directly -Calling the main function from Clojure Oddly, by calling main from Clojure, I get an exception that isn't there when I run normally: UnsupportedOperationException This parser

Re: Handling exceptions (subject renamed)

Awesome. On Fri, Oct 5, 2012 at 8:40 PM, gaz jones wrote: > http://clojure.github.com/clojure/clojure.stacktrace-api.html > > On Fri, Oct 5, 2012 at 12:06 PM, Matt wrote: > > Hi, > > > > Sorry to anyone who read the original post. > > Apparently I had malformed the try block encompassing the c

Re: Handling exceptions (subject renamed)

http://clojure.github.com/clojure/clojure.stacktrace-api.html On Fri, Oct 5, 2012 at 12:06 PM, Matt wrote: > Hi, > > Sorry to anyone who read the original post. > Apparently I had malformed the try block encompassing the create-table in a > very non-clojure-ish way. > So my problem wasn't with cl

Handling exceptions (subject renamed)

Hi, Sorry to anyone who read the original post. Apparently I had malformed the try block encompassing the create-table in a very non-clojure-ish way. So my problem wasn't with clojure.java.jdbc's create-table. Being 'dynamic', clojure could not warn me about it until it crashes in runtime. I g

ClojureScript: catching all javascript exceptions

Hi, I came to the point where I need to be able to catch all javascript exceptions, log them down and swallow. I've been trying to achieve this by (try ... (catch Exception e ...)) (try ... (catch nil e ...)) (try ... (catch js/object e ...)) and nothing seems to do the trick. Coul

Re: reporting function inputs as part of exceptions

nputs (vec ~args)} On 04/09/12 05:03, Timothy Pratley wrote: I'm working on a project where it would be quite convenient to have the input values to the function reported in any exceptions that get thrown. I'm guessing the way to do this would be to create a replacement defn w

Re: reporting function inputs as part of exceptions

t;) {:e e :inputs (vec ~args)} On 04/09/12 05:03, Timothy Pratley wrote: I'm working on a project where it would be quite convenient to have the input values to the function reported in any exceptions that get thrown. I'm guessing the way to do this would be to create a replacemen

Re: reporting function inputs as part of exceptions

f ~@args) (catch Exception e (do (println "oops!") {:e e :inputs (vec ~args)} On 04/09/12 05:03, Timothy Pratley wrote: I'm working on a project where it would be quite convenient to have the input values to the function reported in any exceptions that get thrown. I'm

Re: reporting function inputs as part of exceptions

s to the function reported in any exceptions that get thrown. I'm guessing the way to do this would be to create a replacement defn which had a try catch and threw a new error with the inputs captured. Has anyone tried this, know of a better way, or a library that helps in this way? -- You

Re: reporting function inputs as part of exceptions

gt; input values to the function reported in any exceptions that get thrown. > I'm guessing the way to do this would be to create a replacement defn which > had a try catch and threw a new error with the inputs captured. Has anyone > tried this, know of a better way, or a library

reporting function inputs as part of exceptions

I'm working on a project where it would be quite convenient to have the input values to the function reported in any exceptions that get thrown. I'm guessing the way to do this would be to create a replacement defn which had a try catch and threw a new error with the inputs captured.

Re: Uniform exceptions – Clojure and ClojureScript?

Has anyone made headway on this? Does anyone have good practice that they can share? Cheers Dave On Wednesday, 28 December 2011 08:52:00 UTC+11, Dave Sann wrote: > > I believe the capability to have a portable solution in specific cases is > in the pipeline > > https://github.com/clojure/clo

Re: clojure.core.unify and exceptions

On Jun 6, 2012, at 5:59 PM, Kevin Livingston wrote: > I was surprised to find that clojure.core.unify returns an exception > when something does not unify rather than something like nil (false) > when they don't. You can use core.logic's unifier: user=> (require '[clojure.core.logic :as l]) us

clojure.core.unify and exceptions

it's a quite expected result that they don't. In this use of unification exceptions make a bit of a mess of the flow control (also are they slower?), it makes things less functional. Is there discussion of this decision somewhere? Is there a way to get nil instead? do I just wrap it

Re: Multiple expressions in LET and exceptions

Now that you said it, it all makes perfect sense. I'm in the process of switching from Scheme to Clojure and these are some "bad" habits. This case makes me also realise that dealing with lazy sequences can be a delicate matter in cases where you want eager evaluation, since you really have to call

Re: Multiple expressions in LET and exceptions

Map actually doesn't do anything at all. It simply creates a new lazy sequence. Instead of map, use doseq and you'll get the result you expect. Since you actually never print the result of the map, the lazy sequence is just thrown away, and f is never called, hence never evaluates. Timothy > For

Multiple expressions in LET and exceptions

Hi, I spotted a weird behaviour of 'let' (or equivalently 'defn') when multiple expressions are used in the body of the form. When one of the expressions, but not the last one, throws an exception, it seems to be ignored and the final value of 'let' becomes the value of the last expression. For ex

Re: Uniform exceptions – Clojure and ClojureScript?

I believe the capability to have a portable solution in specific cases is in the pipeline https://github.com/clojure/clojurescript/wiki/Exception-Handling -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@

Uniform exceptions – Clojure and ClojureScript?

Hi, Given that Java and JavaScript have different exception semantics (Java requiring AOT compiled class derived from java.lang.Exception/ java.lang.Throwable and such) I would like to ask the community if anybody has come up with an approach to raise and catch exceptions that work uniformly

re: exceptions from avout

any chance such threads could be on an avout list instead of the general clojure list? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - pleas

Re: Exceptions in Haskell and in Clojure

Incidentally, I was just working on such a thing. I'll send it in a new thread. Jonathan On Sun, Sep 11, 2011 at 7:03 PM, Michael Jaaka wrote: > Couldn't match expected type `(t, t1)' > against inferred type `(t2, t3, t4)' > In the expression: (8, 11, 5) > In the expression: [(1, 2), (8, 11, 5)

Exceptions in Haskell and in Clojure

Couldn't match expected type `(t, t1)'   against inferred type `(t2, t3, t4)'   In the expression: (8, 11, 5)   In the expression: [(1, 2), (8, 11, 5), (4, 5)]   In the definition of `it': it = [(1, 2), (8, 11, 5), (4, 5)]   This was excerpt from Haskell exception, will Clojure have ever somethin

Getting Slime to catch exceptions from spawned threads

How does one go about getting Slime to catch exceptions from spawned threads: user> (.start (Thread. (fn [] (/ 42 0 The above exception ends up "outside" of Slime now; back in the terminal where `lein swank' was started. I tried using a future also, but it has some

Agent error handlers that throw exceptions themselves

The docs don't say anything about what happens if an agent error handler itself throws an exception, but the answer seems to be: absolutely nothing. => (def a (agent 1)) #'bar/a => (set-error-handler! a (fn [_ err] (if (instance? ArithmeticException err)

  1   2   >