what I was trying to say is that to find where the exception is
occurring it is (often) useful to wrap the problem code in a tight
exception trap and figure out exactly where the problem is

I grasp what you are saying as there is a design reason Error is not a
checked exception

My efforts here were directed at assisting OP to find where the
problem is but you are correct that some exceptions need to propagate

On Nov 24, 12:52 pm, Lew <lewbl...@gmail.com> wrote:
>  BelvCompSvs wrote:
>
> > I'm just here to confirm what the other two coders told you ~ I found
> > it on first read place a catch( Throwable ) around the call
> > to .print_result(MyService.
>
> That's actually pretty bad advice.  Don't place a 'catch (Throwable ...)'
> around anything.
>
> > java:62) and look at line 62 in MyService but before you even try that
>
> That's actually pretty good advice.  Take a look at line 62.  (I wonder why
> you didn't identify that line for us, seeing as how you're asking for help)
>
> do Object someObject= ((val=null)?("error"):(val)) all over code as
>
>
>
> Huh?  I don't even understand this advice, much less endorse it.  However,
> every interpretation I put on this advice leads to a really bad idea, so
> I'm going to suggest that whatever this advice means, you should not follow
> it.
>
> What you /should/ do is make sure that references point to something other
> than 'null' before you try to dereference them.
>
> > what you are looking for is a result of many design types telling
> > people that code handles nulls
>
> > it doesn't = you have to go look for it and find it
>
> What?
>
> Maybe if there were some punctuation, capital letters, and complete
> sentences in there I could understand what this guys is suggesting.
>
> when you do, fix it some way.....
>
>
>
> I agree with this advice, which boils down to the oh-so-insightful
> suggestion that "analyze the problem, determine a solution!"  That's good
> advice, and I'm sure you'll find it exceedingly helpful.
>
> Not.
>
> NullPointerExceptions, like other RuntimeExceptions, are a result of
> programmer error, in this case yours.  It means that you have a pointer
> still pointing to 'null', but you tried to use it as if it pointed to
> something not 'null'.  You have to assign your pointers to something not
> 'null', and you have to check your pointers before dereferencing them to
> make sure they aren't 'null'.
>
> As stated upthread, the stack trace (plus my hint) will tell you which
> pointer was pointing to 'null' when you tried to dereference it.
>
> --
> Lew

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to