[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Feature request
Etienne GAGNON writes:
> Archie Cobbs wrote:
> > So the feature request is that the methods of DepthFirstAdapter
> > declare throwing some new exception created for this purpose
> > (call it SemanticException or whatever).
> > Does this make sense? Or is there another way to get around this
> > problem.
> The problem is that implementing your request requires adding a "throws
> SemanticException" to the Switchable.apply() method. This would render
> the use of on the fly anonymous instances quite cumbersome.
> The second point is, if all methods have a "throws SemanticException"
> signature, in what is it different from the implicit "throws
As was mentioned, RuntimeException connotes a more serious error
than just invalid input, more like "internal error" or something.
What would really be needed is a new interface, like Switchable,
in which apply() is declared throws Exception. We could call it
> So, I am not sure that this feature is really an improvement. I would
> need additional convincing arguments.
I'm not sure it's the right answer either.. in any case, the problem
is still a real one it seems to me. We should try to come up with a
"canonical" way to address it, either by saying one should subclass
RuntimeException, or by creating SwitchableExceptable, or whatever.
Clearly the path of least upheaval is the RuntimeException route.
What I've been doing in the meantime is having MyAdapter x contain
a private variable "AnalysisException e". Upon return from tree.apply(x)
the caller checks x.e for any errors. Of course "e" could also be an
array to allow reporting of multiple errors.
The only problem is that when an error occurs, you have to fill in
the analysis info for that node with phony, but acceptible, information.
This is pretty much what standard compilers do anyway when faced with
errors, so perhaps this is the best approach.
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com