From walter at frii.com Fri Feb 1 09:42:19 2002 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:40 2004 Subject: [boulder.pm] error handling Message-ID: I have a question about error handling. Most of my work is CGI-related stuff, and once upon a time I migrated to some custom code (let's call it exeunt() that I'd call when s* hit the fan: &do_this_thing or exeunt("No! do_this_thing failed: $!"); and then exeunt would send a very bland screen to the browser ("Gosh, we're SO sorry, but something unexpected just happened. If it'll make you feel better, feel free to contact somebody@righthere.com, but the system just sent him an e-mail about it.") and in the background I'd be sent a nice e-mail with the system/program in the Subject line and some details in the body like the line number in the program where it happened and whatever error message retrieved out of $! and its ilk. But times have changed, a lot, and I am wondering lazily what mechanisms people use for this kind of error handling, and how they like it. Walter From nagler at bivio.biz Fri Feb 1 11:46:41 2002 From: nagler at bivio.biz (Rob Nagler) Date: Wed Aug 4 23:58:40 2004 Subject: [boulder.pm] error handling In-Reply-To: References: Message-ID: <15450.54401.249742.961726@jump.bivio.com> > But times have changed, a lot, and I am wondering lazily what > mechanisms people use for this kind of error handling, and how > they like it. I like calling die when a problem occurs. I also like having a wrapper which at some contextual information to the internal logs. We have a few problems which result in an email being sent to root. For the most part, we rely on high frequency log parsing. We have a multitiered alert system, which is controlled by regular expressions and counters in the log parser. For example, if we get three die calls of a specific type, we send a page. Otherwise, we send email. Rob From rise at knavery.net Fri Feb 1 16:19:11 2002 From: rise at knavery.net (rise) Date: Wed Aug 4 23:58:40 2004 Subject: [boulder.pm] Ruby User's Group invite / general language discussion Message-ID: The Boulder area Ruby UG has once again reformed from empty air and will be meeting at the BookEnd at 6:30 the night of Wednesday Feb. 6th. This is an open invite to anyone interested in Ruby or languages in general, especially since attendees tend to be Perl or Python programmers dabbling in Ruby (with one glaring exception). Just about anything is fair game and we'll try to keep the gripe session about false vs. null vs. empty to under five minutes of concentrated ranting... -- Jonathan Conway rise@knavery.net Not only is there no accounting for taste, there is no accounting for what can happen when entirely new tech meets bad taste. [John P. Caplinger] From walter at frii.com Mon Feb 4 11:13:45 2002 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:40 2004 Subject: [boulder.pm] error handling In-Reply-To: <15450.54401.249742.961726@jump.bivio.com> Message-ID: On Fri, 1 Feb 2002, Rob Nagler wrote: > > But times have changed, a lot, and I am wondering lazily what > > mechanisms people use for this kind of error handling, and how > > they like it. > > I like calling die when a problem occurs. I also like having a > wrapper which at some contextual information to the internal logs. > > We have a few problems which result in an email being sent to root. > For the most part, we rely on high frequency log parsing. We have a > multitiered alert system, which is controlled by regular expressions > and counters in the log parser. For example, if we get three die > calls of a specific type, we send a page. Otherwise, we send email. > > Rob Huh. I don't call die, but rather the exeunt() function does an 'exit 0' when it's done all the notifying I want it to. I hope that was "obvious" to everyone following along. Here're the thoughts I have on this (and I'm wondering if we're talking about the same things and each leaving out the "obvious" stuff): I like sending the browser a nice, bland "there's a problem and we're working on it" message rather than letting them see a '500 Internal Server Error' message or the results of a die, which might contain system info they have no need to see. (That's a security issue at least as much as an aesthetic one.) When my stuff explodes, I want to know about it. Then again, most of our web programming is straightforward, and if it wants to die, something is WRONG. I'm not sure I understand the value of setting a die-notification threshold to anything but 1. Also, I must confess, I was hoping some folks would chime in with their favorite error-handling tools. There's a whole range of stuff from '500 Internal Server Error' to 'use CGI::Carp qw(fatalsToBrowser)' and redirecting STDERR through custom jobbies (again ranging from simple things like exeunt through elaborate work -- such as Bivio/BoP stuff?) There are SO many tools out there, and we don't all have the time to check out each one of them, regardless of good intentions. Walter From nagler at bivio.biz Mon Feb 4 11:37:44 2002 From: nagler at bivio.biz (Rob Nagler) Date: Wed Aug 4 23:58:40 2004 Subject: [boulder.pm] error handling In-Reply-To: References: <15450.54401.249742.961726@jump.bivio.com> Message-ID: <15454.50920.912238.731809@jump.bivio.com> > Huh. I don't call die, but rather the exeunt() function does an > 'exit 0' when it's done all the notifying I want it to. I hope that > was "obvious" to everyone following along. We seem to be talking apples and oranges. We use mod_perl, where you should never call exit. I imagine this is just the opposite case with CGI. > There are SO many tools out there, and we don't all have the time > to check out each one of them, regardless of good intentions. It would seem to depend on what you're doing. We have a policy of never calling exit, even for command line utilities. The only way to exit cleanly is to return from the main subroutine. This is very specific to bOP. I would think you would have to adhere to whatever policies your framework requires. Most frameworks I've seen define error handling pretty clearly. Sorry for the non-answer... Rob From walter at frii.com Thu Feb 7 19:32:31 2002 From: walter at frii.com (Walter Pienciak) Date: Wed Aug 4 23:58:40 2004 Subject: [boulder.pm] Sr. Perl Programmer contract (fwd) Message-ID: ---------- Forwarded message ---------- Date: 7 Feb 02 14:54:59 MST From: Cathy Gonsalves To: walter@frii.com Subject: Sr. Perl Programmer contract Hello Walter, I found you as the contact for the Boulder Perl Mongers group. I didn't find a place to post our open Perl job so I'm hoping you don't mind me contacting you. If you are interested, or know of anyone who would be, we are looking to employ 3 senior Perl Developers for 3 months. Thank you, Cathy Gonsalves Internet Sourcing Specialist Tiger Technology cathy@tigertechnology.com www.tigertechnology.com ---------------------------- Sr. Perl Programmer +IBM DTC, CO 261 3 contractors needed to work on web project! 3-month contract with our client for a Senior Perl Programmer located in the Denver Tech Center (DTC) area of Englewood, Colorado. Required Skills: Must have Object-Oriented (OO) Perl Must have Mod Perl Must have MySQL (preferred) or SQL Server Must have Unix Restrictions: No third parties No visa transfers or sponsorship Locals Only To Apply: Please send your resume in Word format to jobs@tigertechnology.com