Avoid rescue nil. There are a lot of StandardErrors your don't really want to rescue so it's considered bad form. Checking a hash is unlikely to cause any of them but just something to keep in mind.
I like the way Obj-C (and many other languages) just quietly suppress method calls to nil. In almost all cases where I have nil checking I return nil anyway. That said, it's may confuse people who don't know there's an extension to nil. Martin Emde Tw: @martinemde On Mon, Aug 17, 2009 at 12:53 PM, Bradly <[email protected]> wrote: > Maybe a proxy class for that hash? > -Bradly > > > > On Mon, Aug 17, 2009 at 12:37 PM, Nick Zadrozny <[email protected]>wrote: > >> So I had a moment of disgust over all the nil object checking I'm doing >> when grabbing values that may or may not be present in a multi-level hash. >> You know the code, >> >> @foo.whatsit = params[:widgets][:thingamabob] if params[:widgets] && >>> params[:widgets][:thingamabob] >> >> >> Why not just define [] on NilClass and be done with it? >> >> class NilClass >> >> def [](index=nil) >> >> nil >> >> end >> >> end >> >> >> The purist in me revolts a little bit at this idea. But the pragmatist >> would love to quit making all these nil object checks when I really don't >> care about them. >> >> I suppose I could just do… >> >> @foo.whatsit = params[:widgets][:thingamabob] rescue nil >> >> >> …but that also seems a bit shady, though I certainly can recall seeing >> examples of it in the wild. >> >> Do any of you wrestle with this? Perhaps you have better suggestions to >> save me some typing while appeasing my inner pedant? Or maybe you can tell >> me that both of the above are just fine, you do them all the time, and I >> should quit splitting hairs? >> >> -- >> Nick Zadrozny >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby -~----------~----~----~----~------~----~------~--~---
