So I have a view where I take a date and I run a strftime("%b %d")
date
format a string, right?
Ok, now if the date can be nil ; if that is the case I dont want an
error message being thrown if I call strftime on it. I would ideally
check for nil when I am displaying the value, right? But do I really
have to? If the value is not required then there ought to be a way of
just rendering a warning so we can avoid those nil errors (whiny_nils?)
Do I have to check for nils everytime and everywhere and all over the
place? Checking for nils should be optional if there is a nil the
compiler should just generate a warning and move on... I mean does
anyone remember the java.nullpointerexception horrors?
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
On Jun 23, 2008, at 4:39 PM, Ather Shiraz wrote:> > So I have a view where I take a date and I run a strftime("%b %d") > date > format a string, right? > > Ok, now if the date can be nil ; if that is the case I dont want an > error message being thrown if I call strftime on it. I would ideally > check for nil when I am displaying the value, right? But do I really > have to? If the value is not required then there ought to be a way of > just rendering a warning so we can avoid those nil errors > (whiny_nils?) > Do I have to check for nils everytime and everywhere and all over the > place? Checking for nils should be optional if there is a nil the > compiler should just generate a warning and move on... I mean does > anyone remember the java.nullpointerexception horrors?What''s wrong with? mydate.strftime(...) unless mydate.nil? Makes it very clear what you''re doing... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Philip Hallstrom wrote:> On Jun 23, 2008, at 4:39 PM, Ather Shiraz wrote: > >> (whiny_nils?) >> Do I have to check for nils everytime and everywhere and all over the >> place? Checking for nils should be optional if there is a nil the >> compiler should just generate a warning and move on... I mean does >> anyone remember the java.nullpointerexception horrors? > > What''s wrong with? > > mydate.strftime(...) unless mydate.nil? > > Makes it very clear what you''re doing...That sounds fine but it is just all this extra code that is unnecessary I feel. Why would you want to throw an error message crippling the entire application if some field is nil? There should be a more graceful method where we can avoid even checking for nil because most of the time we forget to check for nil. You see all the required fields have presence of validation in the models but there are these optional fields which can throw these nil errors; we should be able to avoid peppering our scriptlets with .nil?s ; does that make sense? Is it just me? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
One more thing what if a relationship for example user.profile.name has one link in the middle that is nil then again the entire application is littered with nil:nilclass errors! ; we should be able to tackle such errors in data with small tags rather than crippling the entire application. Philip Hallstrom wrote:> On Jun 23, 2008, at 4:39 PM, Ather Shiraz wrote: > >> (whiny_nils?) >> Do I have to check for nils everytime and everywhere and all over the >> place? Checking for nils should be optional if there is a nil the >> compiler should just generate a warning and move on... I mean does >> anyone remember the java.nullpointerexception horrors? > > What''s wrong with? > > mydate.strftime(...) unless mydate.nil? > > Makes it very clear what you''re doing...-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jun 24, 1:20 am, Ather Shiraz <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> One more thing what if a relationship for example user.profile.name has > one link in the middle that is nil then again the entire application is > littered with nil:nilclass errors! ; we should be able to tackle such > errors in data with small tags rather than crippling the entire > application. >It''s a delicate path to tread. In a system where errors are swallowed silently it''s a bloody nightmare to work out what is happening when things don''t work. Fred> Philip Hallstrom wrote: > > On Jun 23, 2008, at 4:39 PM, Ather Shiraz wrote: > > >> (whiny_nils?) > >> Do I have to check for nils everytime and everywhere and all over the > >> place? Checking for nils should be optional if there is a nil the > >> compiler should just generate a warning and move on... I mean does > >> anyone remember the java.nullpointerexception horrors? > > > What''s wrong with? > > > mydate.strftime(...) unless mydate.nil? > > > Makes it very clear what you''re doing... > > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
That is fine during "debugging" and testing phase we can have the errors blow up; but in production these errors should not annoy users with glaring ugly error messages; in production we should have the ability to have silent warnings or separate error logs which post these errors but on the viewer screen. Frederick Cheung wrote:> On Jun 24, 1:20�am, Ather Shiraz <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> > wrote: >> One more thing what if a relationship for example user.profile.name has >> one link in the middle that is nil �then again the entire application is >> littered with nil:nilclass errors! ; we should be able to tackle such >> errors in data with small tags rather than crippling the entire >> application. >> > It''s a delicate path to tread. In a system where errors are swallowed > silently it''s a bloody nightmare to work out what is happening when > things don''t work. > > Fred-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, 2008-06-24 at 03:41 +0200, Ather Shiraz wrote:> That is fine during "debugging" and testing phase we can have the errors > blow up; but in production these errors should not annoy users with > glaring ugly error messages; in production we should have the ability to > have silent warnings or separate error logs which post these errors but > on the viewer screen. > > Frederick Cheung wrote: > > On Jun 24, 1:20�am, Ather Shiraz <rails-mailing-l...@andreas-s.net> > > wrote: > >> One more thing what if a relationship for example user.profile.name has > >> one link in the middle that is nil �then again the entire application is > >> littered with nil:nilclass errors! ; we should be able to tackle such > >> errors in data with small tags rather than crippling the entire > >> application. > >> > > It''s a delicate path to tread. In a system where errors are swallowed > > silently it''s a bloody nightmare to work out what is happening when > > things don''t work. > >---- not wishing to get into a philosophical debate with you but it wouldn''t make any sense to have production mode swallow errors that development mode or testing mode would toss an error...that would defeat the whole design process. I actually count on what works in development or testing to work in production. Consider... you can trap for nil entries in validations and validations are simple you can always test it with .blank? you can always convert nil values to empty strings by simply adding .to_s i.e. test = User.new test.name => nil test.name.to_s => "" Craig --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Craig White wrote:> not wishing to get into a philosophical debate with you but it wouldn''t > make any sense to have production mode swallow errors that development > mode or testing mode would toss an error...I am not advocating swallowing the error just making the error less verbose or less glaring and less of a show stopper; We already have verbose and --trace related error magnification tools. We have whiny_nils=true already in there so that is precisely what I am talking about; However perhaps I am requesting a little more than that.> that would defeat the whole > design process. I actually count on what works in development or testing > to work in production.In development one does not go down every imaginable path ; even in testing one cannot assure that what works in testing/development will work in production; usually in production the end user modifies the data or an anomaly arises which causes the entire application to start throwing these nil.nilclass errors all over the place.> you can trap for nil entries in validations and validations are simplewhat if one forgets these validations ? (nils can still arise when related records are deleted and dependents are left dangling) what if someone deletes a dependent and a dangling pointer remains to that record? it would be cool if that dangling pointers just printed something innocuous like "points to nil" and the application moved on instead of throwing a nil.nilclass error. Again this app. is in development mode in production machine so I dont know precisely how it will react in prod mode.> you can always test it with .blank?test every relationship with a .blank? that is an easy candidate for abstracting .blank and putting it in a lower layer, dont you think?> you can always convert nil values to empty strings by simply > adding .to_s > i.e. > test = User.new > test.name > => nil > test.name.to_s > => ""Thanks will try this one out but this is an example of what I mean. Maybe this is all I need to do, wrap everything in .to_s -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 24 Jun 2008, at 15:10, Ather Shiraz wrote:> >> you can trap for nil entries in validations and validations are >> simple > > what if one forgets these validations ? (nils can still arise when > related records are deleted and dependents are left dangling) what if > someone deletes a dependent and a dangling pointer remains to that > record? it would be cool if that dangling pointers just printed > something innocuous like "points to nil" and the application moved on > instead of throwing a nil.nilclass error. > Again this app. is in development mode in production machine so I dont > know precisely how it will react in prod mode. >If I were you I would worry about preventing bogus data rather than trying to deal with it (eg add some foreign key constraints) Fred>> you can always test it with .blank? > > test every relationship with a .blank? that is an easy candidate for > abstracting .blank and putting it in a lower layer, dont you think? > >> you can always convert nil values to empty strings by simply >> adding .to_s >> i.e. >> test = User.new >> test.name >> => nil >> test.name.to_s >> => "" > > > Thanks will try this one out but this is an example of what I mean. > Maybe this is all I need to do, wrap everything in .to_s > -- > Posted via http://www.ruby-forum.com/. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---