I agree. It is also easier to explain that we walk up the class
hierarchy up to Throwable, then go to 500.js and then use the default.
Compare to "We walk up the class hierarchy, but before we actually
meet Throwable, we use 500.js instead. If this does not work, we use
the default."
Lars
On 18.12.2007, at 14:26, Felix Meschberger wrote:
Am Dienstag, den 18.12.2007, 14:12 +0100 schrieb Tobias Bocanegra:
i don't think that other than a 500.js is needed. or do you have a
valid use case?
Not a use case really, but staying in the line: using 500 for a
Throwable is bridging from an exception over to a status code.
Therefore, I would rather like to stay with the Throwable in the first
place.
Checking for 500 afterwards, sounds reasonable as kind of a catch-all
Regards
Felix
regards, toby
On 12/18/07, Lars Trieloff <[EMAIL PROTECTED]> wrote:
I would prefer simple names over FQ names, but perhaps checking
the FQ
name first and then the SimpleName would allow us to eliminate all
ambiguity.
regards,
Lars
On 18.12.2007, at 13:28, Bertrand Delacretaz wrote:
Hi,
On Dec 18, 2007 1:16 PM, Felix Meschberger <[EMAIL PROTECTED]>
wrote:
...(1) for status codes:...
I assume you mean status codes >= 400, right?
I'm ok with the proposed ScriptOrServlet resolution.
...(2) Likewise for Throwables it would be:
Class<?> tClass = throwable.getClass();
Servlet s = null;
while (s == null && tClass != Object.class) {
s = resolveScriptOrServlet(tClass);,,,
Shouldn't we use Class.getSimpleName() here?So that scripts are
named
MyFunnyException instead of
com.nowhere.somepackage.MyFunnyException?
tClass = tClass.getSuperclass();
}
if (s == null) {
s = defaultErrorHandlerServlet;
}...
Sounds good to me, but we'll have to be careful with exceptions
that
occur while looking up exception scripts (I'm kind of noting the
obvious here ;-)
-Bertrand
--
Lars Trieloff
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
--
Lars Trieloff
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
