The second option sounds simple enough. If matters on the branch weighing are handled appropriately, checking if the address is invalid should be a very miniscule cut by assuming that the validity of the address is by far the most likely branch case. However the Microsoft compiler seems to override that concept at times.

I have no idea what SEH is.

The third option would be the sexiest. Function-oriented templating is always a bit more 1:1 translatable to the human concept, but I would always avoid laying a series out except for cases where the conditional operations were too large or too complex to maintain in the local scope.

Also, I think that writing any code for portability, is a plus anywhere, not just GNU/Linux.
Linux would be a prime example for targeting portability, but keeping code simplicity and purity as a general rule of thumb should suffice over the need of targeting any default operating system.

it does not check if it is rdram on not on read/writes, just executes it.

If it is not, a structured exception occurs, the structure exception handler then looks at the asm opcode causing the error, detects if it is actually in the n64 zone and maps to a n64 register address. If it does then it cause the read/write to register, setups up the x86 ops that should be filled with that value, moves EIP to the next instruction and tells the cpu to continue executing.

Not sure if that would work with signals, possible the whole memory management needs to be re-written to allow porting to linux.

I'm happy to find signals work well for me both on Linux and a 64-bit Windows 7 laptop (on a partition barely big enough to fit Windows on it, never mind pj64).

In fact, I'm not really seeing anything that the C++ try { } catch { } finally { } model is doing that the standard C approach of setting a signal ("exception") handler and doing a longjmp() when raised isn't.

I'm not really understanding what's useful about Project64's C++ try/except/finally that can't be handled portably this way. The only exception (HAHA GET IT?) is the fact the C standard doesn't require all running environments to raise these signals automatically when you try to dereference a NULL pointer or other things. But it does work on both Windows 7 and Linux, and many of the platforms that can't or don't raise the exceptions automatically probably only support the C language and not the C++ language anyway.