I wonder, would it be possible to throw a custom exception (something like
DoNotUse_InternalRuntimeException) in Reflector.java, and update try/catch
code to always unwrap it?
Cheers,
Ivan.
On 12 October 2011 03:44, pmbauer paul.michael.ba...@gmail.com wrote:
I don't know what the right
I've done something like this in Java projects but without any magic
unwrapping. It worked well. Manual unwrapping wasn't too onerous in the rare
cases where we wanted to do so. The Clojure-specific exception should be part
of the public API for Java interop. Don't try to hide it.
On Oct
Hi,
Am Mittwoch, 12. Oktober 2011 15:19:21 UTC+2 schrieb miner:
I've done something like this in Java projects but without any magic
unwrapping. It worked well. Manual unwrapping wasn't too onerous in the
rare cases where we wanted to do so. The Clojure-specific exception should
be part
Hi,
To my humble ears this sounds like the best idea so far. Something like
ClojureRTException ...
Regards,
Stefan
--
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
On Oct 12, 2011, at 1:21 PM, Sean Corfield wrote:
On Wed, Oct 12, 2011 at 7:37 AM, Stefan Kamphausen
ska2...@googlemail.com wrote:
To my humble ears this sounds like the best idea so far. Something like
ClojureRTException ...
The problem - in Clojure code using try/catch - is that you
Stuart Sierra the.stuart.sie...@gmail.com writes:
I was a little worried about this when the exception behavior for fns was
changed. I think it's solvable, but don't know right now what the solution
is.
I'm not incredibly experienced with Java, but would using a Java
construct which tricks
Just for the record: That's how I understood Ivan's idea, too. Introduce a
special exception type which is used nowhere else and unwrap that
automatically.
I am not experienced enough a Java programmer to know all the implications
that may arise here and there.
Regards,
Stefan
--
You
I've attached a RFC patch based on this idea to CLJ-855.
http://dev.clojure.org/jira/browse/CLJ-855
// Ben
On Wed, Oct 12, 2011 at 22:02, Stefan Kamphausen ska2...@googlemail.com wrote:
Just for the record: That's how I understood Ivan's idea, too. Introduce a
special exception type which
On Wed, Oct 12, 2011 at 12:00 PM, Marshall T. Vandegrift
llas...@gmail.com wrote:
Stuart Sierra the.stuart.sie...@gmail.com writes:
I was a little worried about this when the exception behavior for fns was
changed. I think it's solvable, but don't know right now what the solution
is.
I'm
Would a good solution to this be for try/catch to _automatically_
unroll RTE if there's no matching Exception class specified?
I understand _why_ the change to wrap exceptions was made but without
the equivalent unwrapping in try/catch this just moves the pain from
the library/language out to the
I was a little worried about this when the exception behavior for fns was
changed. I think it's solvable, but don't know right now what the solution
is.
-S
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
Would now be a bad time to observe there was a large change made to the way
exceptions are handled, and the lack of guard-rails (no tests for exception
handling behavior) may have contributed to this regression?
https://github.com/clojure/clojure/commit/8fda34e4c77cac079b711da59d5fe49b74605553
…or that there's many thousands of tests (or many, many, many thousands of
tests if you count all the 3rd party libraries that have been testing against
1.3.0 snapshots for months with nary a related hiccup), many of them related to
exceptions and other error conditions, but no one was clever
Fair enough. :) Complete test coverage is intractable.
But in clojure, there are only a handful of tests that contain a catch and none
that test try/catch semantics. Maybe I'm looking in the wrong place...
--
You received this message because you are subscribed to the Google
Groups Clojure
It's not a regression. It is a known breaking change.
The change merely owned up the the fact that we cannot in fact communicate all
actual errors through Java code, due to checked exceptions. This is an enduring
problem with Java, and you are going to see it rear its ugly head in Java
itself
I don't know what the right solution is either, but here is a JIRA ticket
with an attached regression test. A start.
http://dev.clojure.org/jira/browse/CLJ-855
On Tuesday, October 11, 2011 3:02:47 PM UTC-7, Stuart Sierra wrote:
I was a little worried about this when the exception behavior for
I finally came up with a simple example which shows the broken
exception handling behavior I described in my earlier post on this
thread.
(defn broken-catch [filename]
(try (java.io.FileReader. filename)
(catch java.io.FileNotFoundException fnfe
FileNotFoundException caught)
On Oct 3, 9:27 pm, Stuart Halloway stuart.hallo...@gmail.com wrote:
Catching checked exceptions seems to work fine. Try e.g.
(try (throw (java.io.IOException.)) (catch java.io.IOException _ caught!))
I suspect something else is going wrong in the GAE example. Can you narrow
the code down
It does.
user= (defn f [] (Class/forName nonexistant))
#'user/f
user= (try (f) (catch ClassNotFoundException e caught!))
caught!
--
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
On Thu, Oct 6, 2011 at 4:39 AM, Meikel Brandmeyer (kotarak) m...@kotka.de
wrote:
It does.
user= (defn f [] (Class/forName nonexistant))
#'user/f
user= (try (f) (catch ClassNotFoundException e caught!))
caught!
the problem is in Reflector.java and the call to Class/forName is
I ran into an interesting problem while porting appengine-magic to
Clojure 1.3.0.
The Google App Engine SDK uses checked exceptions on many of its API
methods. In many cases, I want to catch these exceptions and do
something Clojure-friendly with them. With Clojure 1.2.x, I had no
trouble
The Google App Engine SDK uses checked exceptions on many of its API
methods. In many cases, I want to catch these exceptions and do
something Clojure-friendly with them. With Clojure 1.2.x, I had no
trouble catching checked exceptions by type, e.g.:
(try
Reflector.java wraps checked exceptions in runtime exceptions
On Mon, Oct 3, 2011 at 12:27 PM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
The Google App Engine SDK uses checked exceptions on many of its API
methods. In many cases, I want to catch these exceptions and do
something
I believe the actual problem comes from things like RT.classForName(),
which internally catches a ClassNotFoundException, and then does this:
throw Util.runtimeException(e);
That ends up just sort of obscuring what the exception is, and you
can't just catch ClassNotFoundException
On Mon, Oct 3, 2011 at 12:03 PM, Constantine Vetoshev
gepar...@gmail.com wrote:
This stopped working in 1.3.0. The caught exception does not match
EntityNotFoundException; it is now a RuntimeException with the
original typed exception chained to it.
This caused me some pain in
On Oct 3, 12:27 pm, Stuart Halloway stuart.hallo...@gmail.com wrote:
Catching checked exceptions seems to work fine. Try e.g.
(try (throw (java.io.IOException.)) (catch java.io.IOException _ caught!))
I suspect something else is going wrong in the GAE example. Can you
narrow the code down to
26 matches
Mail list logo
