NEVER, NEVER, and once again *NEVER* use #ifError:
This protocol was introduced prior to exceptions existing in the
base image. It was made exception aware by capturing the exception,
Error. This is very, very, very bad form. (I have written about this
on more than one occasion, check the archives.)

The problem is that the idiom...

[]
on: Error
do: [:ex | ]

will prevent anyone deeper in the call chain (or the default handler)
from having an opportunity to rectify the exceptional condition. There
was a case in the Win32s implementation of VSE in which an OS bug
was worked around by having a default FileError handler that could
reliably recover from error indications returned from the OS.

Instead, one should wait till *all* handlers have had an opportunity
to attempt recovery, if they can't and the call chain must be unwound,
one would catch instead the fact that the call chain is being 
prematurely
cut short with the following idiom...

[]
ifCurtailed: []

As for the specific case of the compiler, I believe I have heard our
friends in Berne lament the direct reference to morphs in the Compiler
and IIRC Diego has called for some kernel level Exception design.
There should be a family of CompilerError exceptions, (as well as
CollectionError, FileError, etc). The default handler for 
CompilerSyntaxError
should be the one to open the syntax error morph.

In that event, more stylish and intentful code might read as,

[Compiler evaluate: 'xlerb ; frobnozz ;;;']
on: CompilerSyntaxError
do: []