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