Check for Nil Everytime?

What's wrong with?

mydate.strftime(...) unless mydate.nil?

Makes it very clear what you're doing...

Philip Hallstrom 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?

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:

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

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

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 >> 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. >

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 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.

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

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