couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Evans" <>
Subject Two suggestions for error handling in Futon...
Date Wed, 09 Jul 2008 02:13:14 GMT
As you can see in this screenshot
<>, despite having a
desktop resolution of 2560x1600, because Futon uses a javascript alert to
display error messages, the error message is constrainted to about a 300x125
box in the Camino browser (which causes some of the information to be

It's a bit better in Firefox where the entire error message can actually be
seen, but in both cases it blocks me from using my browser for anything else
until I clear the error.

This is especially annoying if I have kicked off some long running operation
(the first query after a view change for example) and the error doesn't
happen right away.

For both of these reasons, I would like to suggest displaying the error in
an overlaid DIV inside the page instead of using alert().

My second suggestion is that something has to be done to transform the
default Erlang error messages into something more helpful for users.  I
actually don't mind Erlang's error reporting as much as most people, but
this is not helpful in the least in my situation:

Error: error


First of all, "Error: error" is obviously redundant... but more importantly,
the best hypothesis I can come up with from this message is that Erlang had
trouble trying to read the response from the (javascript) view server...
because the failure appears to have occured in read_json... and I'm guessing
that the only two places where Erlang is reading json is 1) processing the
request and 2) processing the response from the view server.  I'm assuming
that there should be no problems processing the request which originated
from Futon, but I suppose the other possibility is that something about my
setup cause Futon to send an invalid request?  In any event, in order to
make this usable for the average user, I think that you need an plain
english error message.  Obviously the Erlang error dump can be included so
that more advanced users can take advantage of it, but in the long run, most
users are going to need something like "Error: The server was unable to
process the request because the input was not valid JSON" or "Error: The
JSON produced by the view server was malformed".

In the meantime, any suggestions on what is happening or what I can do to
try to isolate the issue further?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message