Exceptions are not a good way to navigate
JSF. Actually they're not a good way to navigate any webapp, but especially not JSF.
When a JSF method throws an Exception, it exits both JSF and the webapp itself and is caught by the container (the webapp server). If an exception page is defined, the container will construct and dispatch an internal URL request for that page.
JSF is not recommended for any page that is internally invoked by the container. Not only error pages, but login forms or any other page specified in web.xml. That's because the internal URL dispatcher may not invoke the FacesServlet - it's running along a different path than external requests do.
Actually, the "to" navigation element is new to me. Apparently it was added without much comment to JSF2. Most people use annotations and the JSF2 implicit navigation mechanism instead of using faces-config.xml for navigation.
In any event, if you find an error on a JSF page request, the first choice is generally to add it to the view error list and redisplay the page (using a null navigation target). This allows users to correct faulty inputs without having to re-enter all the fdata.
As a second option, where, for example, executing a page action results in a database error,
you should define your own error view and navigate to it rather than throwing an Exception up to the server. The JSF2 Flash scope can be handy when doing this.