Golly, does this break pretty much all existing tags?
(bob scans his bazillion tags...)
I don't really buy the style argument regarding making it easier
for readers vs. authors of tags. I don't think this is a place
to assert a particular dogma.
The issue, as I see it, is about error-handling. Narrowing the
type thrown doesn't help me handle my exceptions at all. Jelly doesn't
care about the type, one way or the other.
As it stands now, you can certainly narrow the exceptions your tags
throw. I can throw or handle whatever I want, easily, without having
to handle exceptions I don't wish to handle, purely to wrap.
While now I can do the following and handle MalformedURLExceptions
if I'm able to, and ignore anything I'm unable to handle.
public void doTag(XMLOutput output) throws Exception
{
URL url = null;
try
{
url = new URL( whatever );
}
catch (MalformedURLException e)
{
url = somethingElse();
}
}
Under the new code I'd have to do this:
public void doTag(XMLOutput output) throws Exception
{
URL url = null;
try
{
url = new URL( whatever );
}
catch (MalformedURLException e)
{
url = somethingElse();
}
catch (Exception e)
{
// a suspicious amount of handling for an
// unhandled exception...
throw new JellyException( e );
}
}
That's not pleasing. Arguing stylistically, I'd say it even forces
me to inject noise or red-herrings into my code, possibly confusing the
reader. "Hey, he's catching and handling all exceptions" instead of
"Hey, he makes no claims about the unhandled exceptions escaping
from this method."
If we had an official vote on this, I'd be close to -1, hate to say.
-bob
On Tue, 28 Jan 2003, Morgan Delagrange wrote:
> ...doTag() signature change stuff...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
