<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><base href="x-msg://9/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Well, I almost didn't use the term defensive programming, but to some handling any fault would be considered defensive.<div><br></div><div>As an example, lets say I'm parsing the value of an HTTP cookie.</div><div><br></div><div>The first pass I just assume the cookie is always good, and code for the correct case (least defensive).</div><div>If the cookie always parses correctly, I'm done, but lets say the parsing code start failing and I see exceptions in my logs. I then want to determine is the parsing failing because the parsing is broken (a software defect) or because of random corruption of the HTTP stream. So usually I'll put enough defensive code (e.g., code which captures exceptions, instead of 'letting it fail'), to log the error cases, and allow processing to continue.</div><div>If the logging shows a defect it can be fixed, if it shows this is general random corruption it can be left in place or replaced with a counter.</div><div><br></div><div>I use mondemand for counters because I can get graphs easily and have systems which use the data streams to alert based on specific changes.</div><div><br></div><div>I think that defensive code is necessary in many cases to handle faults at the extremities of your system (and sometimes internally depending on the boundaries). So calling defensive code a code smell seems to overly generalize it.</div><div><br></div><div>-Anthony</div><div><br></div><div><div><div>On Jun 4, 2013, at 4:48 AM, Peer Stritzinger <<a href="mailto:peerst@gmail.com">peerst@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; ">I'm not sure what you mean by defensive code, but just to be sure:</div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; min-height: 14px; "><br></div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; ">You should never let error reporting influence how you handle faults in your software.<span class="Apple-converted-space"> <span class="Apple-converted-space"> </span></span>Defensive code is a code smell in Erlang.</div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; min-height: 14px; "><br></div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; ">What you coucld do is to have a error logger handler that matches certain often occuring errors and ignores it.<span class="Apple-converted-space"> <span class="Apple-converted-space"> </span></span>Even better it should count them (the count of something unineresting is often interesting).</div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; min-height: 14px; "><br></div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; ">For counting and other metrics you might want to have a look at folsom<span class="Apple-converted-space"> </span><a href="https://github.com/boundary/folsom">https://github.com/boundary/folsom</a></div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; min-height: 14px; "><br></div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; ">-- Peer</div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; min-height: 14px; "><br></div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; min-height: 14px; "><br></div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; ">On 2013-06-03 17:29:54 +0000, ANTHONY MOLINARO said:</div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; min-height: 14px; "><br></div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">I'd recommend addressing the other crashes with "defensive code". By capturing and categorizing certain types of errors and clearing those from your logs you'll be able to better see true errors. I usually have a two phase approach. First phase, I capture and log the types of errors. Second, once I see certain types are regular I replace those with metrics (via mondemand). Once you have a stream of errors you can then monitor the rates, plus uncaught errors will make it into your logs which should remain very sparse.</div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); min-height: 19px; "><br></div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">-Anthony</div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); min-height: 19px; "><br></div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">On Jun 3, 2013, at 9:11 AM, Ransom Richardson <<a href="mailto:ransomr@talko.com">ransomr@talko.com</a>> wrote:</div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">Are there tools/procedures that are recommended for processing crash reports from a service running at scale?</div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); min-height: 19px; "><br></div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">Currently we have a limited deployment and I look through all of the crash reports by hand. Some are very useful for finding actual bugs in our code. But other crashes are the result of client's sending bad data, strange timing issues (mostly not in our code), etc and are not actionable. As we prepare to scale up our service, I'm wondering how to continue to get the value from the interesting crash reports without having to look through all of the uninteresting ones. </div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); min-height: 19px; "><br></div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">I haven't found rb to be very useful for finding the new/interesting crashes. Are there effective ways that peopler are using it?</div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); min-height: 19px; "><br></div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">Are there other tools for parsing and grouping crash reports to make it easy to find new/interesting ones?</div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); min-height: 19px; "><br></div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">thanks,</div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">Ransom</div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); min-height: 19px; "><br></div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">_______________________________________________</div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); ">erlang-questions mailing list</div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); "><span class="s1" style="text-decoration: underline; "><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></span></div><div style="margin: 0px 0px 0px 12px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Helvetica; color: rgb(1, 24, 146); "><span class="s1" style="text-decoration: underline; "><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></span></div><div style="margin: 0px; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; min-height: 14px; "><br></div>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></div></blockquote></div><br></div></body></html>