On Aug 2, 5:08 pm, JKid314159 <[email protected]> wrote:
> Dear Miga
> QUESTION: (above statement)
> aa) I catch number larger than 20 but can not catch number less than
> -999,999,999. or greater than 999,999,999. NumberFormatException picks this
> up. Problem is that number is no longer integer. How to override?
Another Exception, something near Overflow (I don't remember exactly
the Exception, but you may browse the API, you will find it.
If you have run the program in the labs, which tests for a lot of
exceptions, you should have encountered this type of exceptions. The
best way to learn exceptions is to change the program so that it
catches really on the exceptions already in the program, and maybe
others which are not. It is possible, and when you do it, you'll sure
you have already learnt half of the exceptions classes. The next step
is to make the same kind of tests with a file (local or not).
That's relatively easy as all the methods or classes that throw
exceptions are documented in the api. If you for example rewrite all
the programs viewed in the lessons so far with exceptions, you will
learn a lot.
> ---------------------------------------------------------------------------
> -------------------
> QUESTION: (above statement)
> bb) Not too sure why I need to assert positive when if statement test
> condition for negative number?
> ---------------------------------------------------------------------------
> -------------------
Ah, yes, it's confusing. You just need to think assert as I say this
should be positive, and if it is not it returns an AssertionError,
that's why in the AssertionError you put a message saying it should
not be negative.
Note that the test if negative goes after the assertion, so that at
the moment of the assertion you have not tested so far that the number
is negative or positive or nul. You have only tested that it is a
number with the NumberFormatException, which goes before the
assertion.
As I said earlier, assertions and exceptions are completely decoupled.
Assertions are only activated when you use the flag for it as argument
for the program, otherwise the code for assertions is not executed.
Think of assertions as a way to debug a program at a high level. It
may be useful to let it in the code so that you can tell the client to
activate it when he encounters an error which origin is not extremely
clear.
As for your "Wow, lot of learning in this lesson": if you have not
found the same degree of "Wow, lot of learning" in the other lessons,
you may be sure that you've missed to catch some/many things in them.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaprogrammingwithpassion?hl=en
-~----------~----~----~----~------~----~------~--~---
