On Fri, Apr 7, 2017 at 7:58 AM, Shane Curcuru <[email protected]> wrote: > I'd like to implement better error handling and display. Comments or > suggestions for implementation simplification appreciated. > > Right now, scripts either complete successfully (which the user knows > because content appears on the screen), or often just throw a 500 error > (meaning someone with permissions needs to look in /members/log). It > would be much more polite to > > I'm hoping this can all be encapsulated cleanly in the future Wunderbar > extensions I'm trying to build, like in test/trademark.cgi:
Error handling varies widely from tool to tool. Indeed tools tend to throw a 500 error if they can't be loaded at all. Most simple scripts will run commands on your behalf and will present the output (stdin, stdout, stderr). The agenda tool will show the error in a pop up and return the traceback in your browser's javascript log. The secretarial mail tool is the most advanced in that it presents a list of what it is about to do and dynamically updates that list as the commands complete. Even that tool could improve to provide more recovery options on failure. There is a lot of room for improvement. > class Wunderbar::HtmlMarkup > def _whimsy_header style, title > # Output logos, simple whimsy-wide code/questions/about links, etc. > end > > def _whimsy_cleanup options-needed? > # Function to call at the end of a script > if error then > with body[id = 'script-error'] do > .visible > .content = $stacktrace.simplified > end > else > body[id = "script-ok"].content = "OK" > end > end > > script-ok would be bootstrap badge in the end of the top navbar, which > would appear when content is added to let the user know the ruby script > has completed fully Obviously, this is most important for scripts that > just create large tables, to let the user know the entire table was > completed. > > script-error would be a bootstrap alert-error block below the navbar, > and would appear with some sort of stacktrace to let the user know the > script itself caused an error, and what it was. This is far easier to > debug script errors than looking in the server logs. > > I'm using this new file to test the concept, and will move to lib/asf > once it passes muster (or once someone shows me the right way to do it) The code above looks like a delightful mix of Ruby, Python, JavaScript, and CSS. :-) Be aware that wunderbar runs on the server, and does not have direct access to the browser DOM. The most it can do is to return structured data in the response. The tool would need to include javascript code to examine that response and take action. > I also hope to add 500/401/404 custom error pages as static html, > presumably by updating the httpd.conf stuff here: > > https://github.com/apache/infrastructure-puppet/blob/deployment/data/nodes/whimsy-vm3.apache.org.yaml#L171 Sounds good to me. Just be aware of the infrastructure team's workflow: https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo https://github.com/apache/whimsy/blob/master/DEPLOYMENT.md > -- > > - Shane > https://www.apache.org/foundation/marks/resources - Sam Ruby
