Assert & writing code that should never be reached

Question

hi dudes,
i thing i got that assertion-stuff right BUT there is one thing confusing me:
from my book:
"The following idiom can be employed to explicitly test that certain locations in the code will never be reached.
assert false : "This line should never be reached.";
but what is the point of writing code(at all) that will never be reached?
i mean if it should never be reached ill simply never write it.
even in this tricky EXAMPLE
int someMthd(int trinityMember)
switch (trinityMember) {
    case THE_FATHER:
        return psalm101;
    case THE_SON:
        return psalm102;
    case THE_HOLY_GHOST:
        return psalm103;
    default:
        assert false: trinityMember; //Ok BETTER WOULD BE throw new AssertionError(trinityMember);
}if no case match i would get COMPILE TIME error so that will indicate me that method could(possible) never return an int. So if a i can compile it it will be ok!?
so again what is the point of writing code that should never be reached[\b]?

Answer 1

if no case match i would get COMPILE TIME error so
that will indicate me that method could(possible)
never return an int. So if a i can compile it it will
be ok!?But without the default case you can't compile it, so you have to write a default case (or some other code). What code would it make sense to put there other than throwing an exception of some sort or returning a default value?
so again what is the point of writing code that
should never be reached[\b]?You probably believe the code should never be reached in your example because to you it only makes sense to pass either THE_FATHER, THE_SON or THE_HOLY_GHOST as a parameter. But what if somebody were to pass THE_FIRESTARTER to your someMthd method, having not realised that you haven't coded for that argument? What should your code do then? It can't do nothing, so it makes sense to provide a default case that lets the user know (by throwing an exception), that something unexpected has happened. Or, you might decide to return a default value that is useful and perhaps somehow informs client code of the unusual circumstance (for example a return value of -1 might indicate that there is no relevant psalmX).
So this is about robustness - making sure that in unexpected circumstances, your application does something reasonable.