The following works in REPL, in case the database is down I get the map back.
(try
(insert-table "db" "table" {:id 1 :text "text"})
(catch Exception e {:err "can't connect to database"}))
I though I could write a function that takes a db operation and wrap it with a (try).
(defn catch-db-connection-errors
[db_operation]
(try
(db_operation)
(catch Exception e {:err "can't connect to database"})))
It does not catch the exception though. I might just overlook something very simple...
The problem is that the form you pass in as an argument (e.g. (insert-table "db" "table" {:id 1 :text "text"})) is evaluated before the function is called, and the resulting value is passed into the function. To use another example, if you write (println (+ 1 1)), Clojure will first evaluate (+ 1 1) to get 2, and then will call (println 2). So if an exception is thrown in your DB code, it's before the catch-db-connection-errors function is called and thus outside the try form.
What you want is a macro, which thankfully is something Clojure is great at.
(defmacro catch-db-connection-errors [& db-operations]
`(try
~#db-operations
(catch Exception e {:err "can't connect to database"})))
This allows you to pass in however many database-handling forms you want and wraps them in your try-catch pair.
(Incidentally, you might want to catch something a little more specific than Exception, or else you could end up catching exceptions you don't intend do. But of course that's beside the point here.)
Related
I am learning Clojure, and I would like to create a macro that works like Javas try-catch.
If an exception is thrown, the exception should be returned. Otherwise, the result should be returned.
Any resource that is open should also be closed in the finally section (Without the use of with-open). However, I do have one problem except not being caught that I don't know how to solve. Any help or suggestion would be appreciated!
Here is my code:
(defmacro my-try
([expression]
`(try
~expression
(catch Exception e# e#)
)
)
([[value variable] expression]
`(let [~value ~variable]
(try
~expression
(catch Exception e# e#)
(finally (if (instance? java.io.Closeable ~value) (.close ~value)))
)
)
)
)
When I try to open and read from a file that does not exist:
(def v (my-try [s (FileReader. (File. "missing-file"))] (. s read)))
(println v)
I get the following error:
Execution error (FileNotFoundException) at java.io.FileInputStream/open0 (FileInputStream.java:-2).
missing-file (Det går inte att hitta filen)
I suspect that this error message is an uncaught exception because (1) it does not follow the structure of other exceptions, and (2) if I change the format of the exception return, such as adding a specific message, the error message still does not change.
Any help in finding out what is at fault is highly appreciated!
Many thanks for considering my request.
In (let [~value ~variable], ~variable is evaluating to (FileReader. (File. "missing-file")), but that's outside of the try. It would become something like this:
(let [s (FileReader. (File. "missing-file"))]
(try
(. s read)
. . .
))
Move the let into the try, then expression into the let body.
Also, like in all languages, (catch Exception e# e#) is pretty much universally a bad idea. Throwing away errors becomes a nightmare once anything remotely non-trivial happens, since you've thrown out your only evidence of the problem.
In the following code I'm dispatching two on-click events:
;; event
(reg-event-db
:some
(fn [db [_ some-val]]
(prn "The db is" db)
(assoc db :some some-val)
))
;; another event
(reg-event-db
:another
(fn [db [_ another-val]]
(prn "The db is" db)
(assoc db :another another-val)
))
;; button
[:input {:type "button" :value "Button"
:on-click #(do
(dispatch [:some :some-val])
(dispatch [:another :another-val]))}]
But instead of printing the db map, it prints "The db is" #object[Object [object Object]], and then
Error: No protocol method IAssociative.-assoc defined for type object: [object Object]
What am I doing wrong? I also tried doing #(dispatch [:some :some-val :another another-val] but that gave the same error. In general, how to correctly dispatch two events?
This is correct:
(do
(dispatch [:first-event :some-value])
(dispatch [:second-event :other-value]))
This is not correct:
(dispatch [:some :some-val :another another-val])
In this example, you are dispatching one event with 3 arguments:
:some is the event name,
:some-val is the first argument,
:another is the second argument,
another-val is the 3rd argument.
The error you are encountering doesn't come from the way you dispatch events, but rather from your db state. Let's dissect it step by step:
If (prn db) outputs #object[Object [object Object]] it means db is a JavaScript object.
If (assoc db …) fails with No protocol method IAssociative.-assoc defined for type object: [object Object], it means the db value does not support the assoc function. The assoc function is defined by a protocol (think interface) and this protocol is implemented on maps. So here, db is not a map.
Why would db be a JavaScript object instead of a Clojure map?
When you use (reg-event-db :event-name handler-function), the value returned by handler-function will replace the db state. If by mistake you return a JS object, it will become the new db value, and this new incorrect db value will get passed to subsequent event handlers. So it's highly probable that one of your event handlers is returning a JavaScript object.
How I would solve this situation:
use (js/console.log db) instead of (prn db). You'll be able to see what's inside this js object. prn doesn't know how to print js objects properly.
make sure cljs-devtools is installed and running. It allows you to explore complex objects in the console. Next time this issue arises, you'll immediately see what's the problematic value instead of an opaque string representation.
use reg-event-fx instead of reg-event-db. While a little bit more verbose, it will make more explicit to the human eye what value you are putting in db.
if you want to go further and ensure this never happens again, take a look at Re-Frame Middlewares. In your case, middlewares would allow you to act on handlers returned values, and potentially reject it if it doesn't match your expectations.
I'm working on a game using the big-bang style of programming where one defines the entire state as a single data structure and manages state change by swapping against a single atom.
In a game we cannot trust data sent by the client thus the server has to anticipate the possibility that some moves will be invalid and guard against it. When one writes a function for swapping world state it can start out pure; however, one must consider the possibility of invalid requests. I believe to effect the unhappy path in idiomatic Clojure one simply throws exceptions. So now functions that might have been pure are infected with side-effecting exceptions. Perhaps this is as it has to be.
(try
(swap! world update-game) ;possible exception here!
(catch Exception e
(>! err-chan e))
My aim is to defer side-effects until the last possible moment. I've hardly forayed into Haskell land but I know the concept of the Either monad. When one considers the happy and unhappy path one understands there are always these 2 possibilities. This has me thinking that swap! by itself is insufficient since it ignores the unhappy path. Here's the spirt of the idea:
(swap-either! err-chan world update-game) ;update-game returns either monad
Has the Clojure community adopted any more functional approaches for handling exceptions?
I tend to take a couple different approaches in cases like this. If the state is being updated in a single location I tend to go with:
(try
(swap! world update-game) ;possible exception here!
(catch Exception e
(>! err-chan e)
world) ;; <--- return the world unchanged
or if it's set in lots of places ad a watcher that throws the exception back to the place where swap! was called and doesn't change the state:
user> (def a (atom 1))
#'user/a
user> (add-watch a :im-a-test (fn [_ _ _ new-state]
(if (even? new-state)
(throw (IllegalStateException. "I don't like even numbers")))))
#object[clojure.lang.Atom 0x5c1dc37e {:status :ready, :val 1}]
user> (swap! a + 2)
3
user> (swap! a + 3)
IllegalStateException I don't like even numbers user/eval108260/fn--108261 (form-init8563497779572341831.clj:2)
Please see #7755661 first. I am using ECL and basically want to execute some code, trap any kind of condition that may occur and then continue execution, without prompting or entering the debugger. This is easy to achieve with the following handler-case macro:
(handler-case
(load "code.lisp") ; this may raise a condition
(error (condition)
(print condition))) ; this prints sth like #<a UNBOUND-VARIABLE>
My only problem is that I cannot find a generic way to print a more meaningful error for the user. Indeed my application is an HTTP server and the output goes to a web page. code.lisp is written by the user and it can raise any kind of condition, I do now want to list them all in my code. I would just like to print the same error message I see on the REPL when I do not use handler-case, but in the HTML page, e.g. for an "unbound variable" error, a string like "The variable VAR is unbound".
By inspecting a condition object of type UNBOUND-VARIABLE I see it has two slots: SI:REPORT-FUNCTION, which is a compiled function and SI:NAME, set to the name of the variable in this case. I guess SI:REPORT-FUNCTION could be what I need to invoke but how can I call it? If I try:
(handler-case foo (error (condition) (SI::REPORT-FUNCTION condition)))
it tells me that SI:REPORT-FUNCTION is undefined. SI or SYS in ECL is a package for functions and variables internal to the implementation, but I don't worry if my code is not portable, as long as it works.
BTW in other kinds of condition objects there are also other apparently useful slots for my purpose, named SI:FORMAT-CONTROL and SI:FORMAT-ARGUMENT, but I cannot access any of them from my code too.
I was looking for somethink alike to the getMessage() method of Java exception objects in Lisp, but none of my sources ever mentions something like that.
Moreover, is there any hope to be able to get the line number in code.lisp where the error occurred too? Without that it would be difficult for the user to locate the problem in his code.lisp source file. I would really want to provide this information and stopping at the first error is acceptable for me.
In Common Lisp when print escaping is disabled, the error message is printed.
CL-USER > (handler-case
a
(error (condition)
(write condition :escape nil)))
The variable A is unbound.
#<UNBOUND-VARIABLE 4020059743>
Note that PRINT binds *print-escape* to T.
Using PRINC works - it binds *print-escape* to NIL.
CL-USER > (handler-case
a
(error (condition)
(princ condition)))
The variable A is unbound.
#<UNBOUND-VARIABLE 4020175C0B>
This is described in CLHS 9.1.3 Printing Conditions.
Also note, when you have an object, which has a slot and the value of this slot is a function, then you need to get the slot value using the function SLOT-VALUE and then use FUNCALL or APPLY and call the function with the correct arguments.
If you have a condition of type simple-condition then it has a format-control and a format-argument information. This is described with an example how to use it for FORMAT in CLHS Function SIMPLE-CONDITION-FORMAT-CONTROL, SIMPLE-CONDITION-FORMAT-ARGUMENTS
My answer below is based on one I already gave at the ECL mailing list. Actually I would claim that this is not an embedding problem, but a Lisp one. You want to get some information at the file position of the form which caused the error. This is not attached to a condition because conditions happen independently of whether the form evaluated was interpreted, compiled or part of a function that is already installed in the Lisp image. In other words, it is up to you to know the position of the file which is being read and do some wrapping that adds the information.
The following is nonstandard and prone to change: ECL helps you by defining a variable ext::source-location when LOAD is used on a source file. This variable contains a CONS that should NEVER be changed or stored by the user, but you can get the file as (CAR EXT:*SOURCE-LOCATION*) and the file position as (CDR EXT:*SOURCE-LOCATION*). The plan is then to embed your LOAD form inside a HANDLER-BIND
(defparameter *error-message* nil)
(defparameter *error-tag* (cons))
(defun capture-error (condition)
(setf *error*
(format nil "At character ~S in file ~S an error was found:~%~A"
(cdr ext:*source-location*)
(car ext:*source-location*)
condition)))
(throw *error-tag* *error-message*))
(defun safely-load (file)
(handler-bind ((serious-condition #'capture-error))
(catch *error-tag*
(load file)
nil)))
(SAFELY-LOAD "myfile.lisp") will return either NIL or the formatted error.
In any case I strongly believe that relying on LOAD for this is doomed to fail. You should create your own version of LOAD, starting from this
(defun my-load (userfile)
(with-open-file (stream userfile :direction :input :external-format ....whateverformat...)
(loop for form = (read stream nil nil nil)
while form
do (eval-form-with-error-catching form))))
where EVAL-FORM-.... implements something like the code above. This function can be made more sophisticated and you may keep track of file positions, line numbers, etc. Your code will also be more portable this way.
So please, read the ANSI Spec and learn the language. The fact that you did not know how to print readably a condition and instead tried to play with ECL internals shows that you might face further problems in the future, trying to go with non-portable solutions (hidden slot names, report functions, etc) instead of first trying the standard way.
I'm writing a REST service in Erlang and need to verify the received data before passing it to other internal functions for further processing; in order to do that, I'm currently using nested case expressions like this:
case all_args_defined(Args) of
true ->
ActionSuccess = action(Args),
case ActionSuccess of
{ok, _} -> ...;
{fail, reason} -> {fail, reason}
end,
_ ->
{fail, "args not defined"}
end,
...
I realize this is kind of ugly, but this way I can provide detailed error messages. Additionally, I don't think the usual make it crash philosophy is applicable here - I don't want my REST service to crash and be restarted every time somebody throws invalid arguments at it.
However, I'm considering abandoning all those cases in favor of an umbrella try/catch block catching any badmatch errors - would this work?
fun() ->
true = all_args_defined(Args),
{ok, _} = action(Args).
%% somewhere else
catch fun().
Since what you want to achieve is error reporting, you should structure the thing around the execution of actions and reporting of the result. Perhaps something like this:
execute(Action, Args) ->
try
check_args(Args),
Result = action(Action, Args),
send_result(Result)
catch
throw:{fail, Reason} ->
report_error(Reason);
ExceptionClass:Term ->
%% catch-all for all other unexpected exceptions
Trace = erlang:get_stacktrace(),
report_error({crash, ExceptionClass, Term, Trace})
end.
%% all of these throw {fail, Reason} if they detect something fishy
%% and otherwise they return some value as result (or just crash)
action(foo, [X1, X2]) -> ...;
action(foo, Args) -> throw({fail, {bad_arity, foo, 2, Args}});
action(...) -> ...
%% this handles the formatting of all possible errors
report_error({bad_arity, Action, Arity, Args}) ->
send_error(io_lib:format("wrong number of arguments for ~w: "
"expected ~w, but got ~w",
[Action, Arity, length(Args)]));
report_error(...) -> ...;
report_error({crash, Class, Term, Trace}) ->
send_error(io_lib:format("internal error: "
"~w:~w~nstacktrace:~n~p~n",
[Class, Term, Trace])).
I've had this problem while developing an application that create users.
I first come with a solution like this:
insert() ->
try
check_1(), % the check functions throw an exception on error.
check_2(),
check_3(),
do_insert()
catch
throw:Error1 ->
handle_error_1();
throw:Error2 ->
handle_error_2();
_:Error ->
internal_error()
end.
The problem with this solution is that you lose the stack trace with the try...catch block.
Instead of this, a better solution is:
insert() ->
case catch execute() of
ok -> all_ok;
{FuncName, Error} ->
handle_error(FuncName, Error);
{'EXIT', Error} ->
internal_error(Error)
end.
execute() ->
check_1(), % the check functions throw an exception on error.
check_2(),
check_3(),
do_insert().
This way you have the full error stack on Error.
I have faced exactly the same question when writing my own REST services.
Let's start with the philosophy:
I like to think of my applications like a box. On the inside of the box are all of the parts I built and have direct control over. If something breaks here, it's my fault, it should crash, and I should read about it in an error log. On the edge of the box are all of the connection points to the outside world - these are not to be trusted. I avoid exception handling in the inside parts and use it as needed for the outer edge.
On similar projects I have worked on:
I usually have about a dozen checks on the user input. If something looks bad, I log it and return an error to the user. Having a stack trace isn't particularly meaningful to me - if the user forgot a parameter there is nothing in my code to hunt down and fix. I'd rather see a text log that says something like: “at 17:35, user X accessed path Y but was missing parameter Z”.
I organize my checks into functions that return ok or {error, string()}. The main function just iterates over the checks and returns ok if they all pass, otherwise it returns the first error, which is then logged. Inside of my check functions I use exception handling as needed because I can't possibly consider all of the ways users can screw up.
As suggested by my colleagues, you can alternatively have each check throw an exception instead of using a tuple.
As for your implementation, I think your idea of using a single exception handler is a good one if you only have the single check. If you end up needing more checks you may want to implement something like I described so that you can have more specific logging.