You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2005/03/10 10:13:26 UTC
Re: trunk use case exceptions
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>
>>> I'm a bit concerned with the user-friendlyness of the error handling,
>>
>>
>>
>> Feel free to make a proposal! The usecase framework is still
>> in the "incubation" stage :)
>
>
> OK
> By user-friendliness I mean specifically a language-sensitive error
> message (and of course one providing as much info as possible)
> One way would be to subclass UsecaseException for the individual use
> cases, but I don't see how these could be meaningfully handled.
I'm strongly against using exceptions as a means to provide
the user with information. If an exception is thrown, it means a
programming or setup error occured. A stack trace and a "contact your
administrator" message should do here, we can't provide useful information
for any case anyway.
Any predictable errors should be checked in doCheckPreconditions()
and doCheckExecutionConditions(), informing the user using addErrorMessage().
The errorMessages should certainly be i18nalized, Gregor already
pointed this out. It shouldn't be that hard, we would just have
to use i18n tags in the JX templates.
> So another way might be to use keys, which are then looked up in i18n.
> Or is this unwise mixing of UI and logic ? (personally I don't think so
> since the use case is precisely the code which is handling the user
> interaction)
>
> So proposal 1 :)
>
> UsecaseException gets an additional constructor, taking as parameters an
> (i18n) String key and a list of parameters
> I see that Usecase.execute() already declares a "UsecaseException"
> However, doExecute() a general "Exception". It might make sense to have
> doExecute() throw UsecaseException only.
-1 (see above, misuse of exceptions for control flow and message passing)
I've seen some projects using exceptions this way, this always led
to problems and confusion.
> Example: in the delete group use case,
> if the group parameter is null,
> throw new UsecaseException("group.notfound", new String[]{groupId});
> if the group manager throws an exception "e" when removing,
> throw new UsecaseException("group.delete", new String[]{groupId}, e);
>
> The framework's error handling can then use the key + parameters for
> i18n translate.
>
> Does that make sense ?
I really appreciate your thoughts and ideas, but IMO this concept shouldn't be
implemented using exceptions.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: trunk use case exceptions
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>
>>>> Yes, definitely. I thought at the moment the Cocoon exception screen
>>>> appears, with the stack trace attached. If it doesn't, IMO we should
>>>> change it.
>>>
>>>
>>>
>>>
>>> You are right, it does.
>>> However I suppose we'll want to switch that to a custom Lenya error
>>> page;
>>
>>
>>
>> You mean for brand issues? Or are there any other benefits?
>
>
> It creates a bad impression to users to see the Cocoon error page
> instead of a custom page.
> Personally I don't care ;) but I know many people who do. "The server
> crashed" is what they say to the boss in meetings if they saw a page
> like the Cocoon error page ... I'm not kidding :/
OK, I see your point. There should be a switch (debug/production) to
enable/disable the Cocoon error screen (which is IMO very convenient).
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: trunk use case exceptions
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
>>> Yes, definitely. I thought at the moment the Cocoon exception screen
>>> appears, with the stack trace attached. If it doesn't, IMO we should
>>> change it.
>>
>>
>>
>> You are right, it does.
>> However I suppose we'll want to switch that to a custom Lenya error page;
>
>
> You mean for brand issues? Or are there any other benefits?
It creates a bad impression to users to see the Cocoon error page
instead of a custom page.
Personally I don't care ;) but I know many people who do. "The server
crashed" is what they say to the boss in meetings if they saw a page
like the Cocoon error page ... I'm not kidding :/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: trunk use case exceptions
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>
>> (...)
>>
>>> On a related note: what I've seen in other projects is that the
>>> exception is copied in the resulting HTML, as a comment. That way the
>>> user gets a general message (as is the case now), but if the user is
>>> a developer, she can look at the HTML source code and see the
>>> complete exception in a comment. This allows for faster error
>>> tracing. Would that make sense here ?
>>
>>
>>
>> Yes, definitely. I thought at the moment the Cocoon exception screen
>> appears, with the stack trace attached. If it doesn't, IMO we should
>> change it.
>
>
> You are right, it does.
> However I suppose we'll want to switch that to a custom Lenya error
> page;
You mean for brand issues? Or are there any other benefits?
> at that time we should copy the stack trace to the HTML source, as
> a comment
Yes, if a "clean" error screen is used, we could move it to a
comment to hide it from the user.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: trunk use case exceptions
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
> (...)
>> On a related note: what I've seen in other projects is that the
>> exception is copied in the resulting HTML, as a comment. That way the
>> user gets a general message (as is the case now), but if the user is a
>> developer, she can look at the HTML source code and see the complete
>> exception in a comment. This allows for faster error tracing. Would
>> that make sense here ?
>
>
> Yes, definitely. I thought at the moment the Cocoon exception screen
> appears, with the stack trace attached. If it doesn't, IMO we should
> change it.
You are right, it does.
However I suppose we'll want to switch that to a custom Lenya error
page; at that time we should copy the stack trace to the HTML source, as
a comment
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: trunk use case exceptions
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
[...]
> But I'm wondering how things will be when we use use cases in other user
> interaction scenarios - we'll see when we get there.
Yes, we'll find a way :)
> On a related note: what I've seen in other projects is that the
> exception is copied in the resulting HTML, as a comment. That way the
> user gets a general message (as is the case now), but if the user is a
> developer, she can look at the HTML source code and see the complete
> exception in a comment. This allows for faster error tracing. Would that
> make sense here ?
Yes, definitely. I thought at the moment the Cocoon exception screen
appears, with the stack trace attached. If it doesn't, IMO we should
change it.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: trunk use case exceptions
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
> (...)
> I'm strongly against using exceptions as a means to provide
> the user with information. If an exception is thrown, it means a
> programming or setup error occured. A stack trace and a "contact your
> administrator" message should do here, we can't provide useful information
> for any case anyway.
>
> Any predictable errors should be checked in doCheckPreconditions()
> and doCheckExecutionConditions(), informing the user using
> addErrorMessage().
> The errorMessages should certainly be i18nalized, Gregor already
> pointed this out. It shouldn't be that hard, we would just have
> to use i18n tags in the JX templates.
OK, I understand - exception in doExecute() means some system error.
Whereas other errors would be handled in doCheckPreconditions() and
doCheckExecutionConditions() - that wasn't clear to me thus far, but
seems perfectly plausible.
In fact, so far I'm only looking at use cases in the admin area, and
exceptions there necessarily mean a programming or setup error within
Lenya ! So telling the user to complain to the administrator makes
sense. You are right, there really isn't anything more we can tell a
"normal" user in this situation.
But I'm wondering how things will be when we use use cases in other user
interaction scenarios - we'll see when we get there.
On a related note: what I've seen in other projects is that the
exception is copied in the resulting HTML, as a comment. That way the
user gets a general message (as is the case now), but if the user is a
developer, she can look at the HTML source code and see the complete
exception in a comment. This allows for faster error tracing. Would that
make sense here ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: trunk use case exceptions
Posted by Andreas Hartmann <an...@apache.org>.
Gregor J. Rothfuss wrote:
> Andreas Hartmann wrote:
>
>> Any predictable errors should be checked in doCheckPreconditions()
>> and doCheckExecutionConditions(), informing the user using
>> addErrorMessage().
>> The errorMessages should certainly be i18nalized, Gregor already
>> pointed this out. It shouldn't be that hard, we would just have
>> to use i18n tags in the JX templates.
>
>
> it probably helps to come up with a naming convention for the i18n keys,
> something like addErrorMessage("admin.userGroups.nosuchuser");
+1
{usecase-name}.{message-key} is certainly a good convention
BTW, we should move the JX message output loop to a separate file for
better modularization.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: trunk use case exceptions
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> Any predictable errors should be checked in doCheckPreconditions()
> and doCheckExecutionConditions(), informing the user using
> addErrorMessage().
> The errorMessages should certainly be i18nalized, Gregor already
> pointed this out. It shouldn't be that hard, we would just have
> to use i18n tags in the JX templates.
it probably helps to come up with a naming convention for the i18n keys,
something like addErrorMessage("admin.userGroups.nosuchuser");
and the i18n file then has the appropriate translation.
--
Gregor J. Rothfuss
COO, Wyona Content Management Solutions http://wyona.com
Apache Lenya http://lenya.apache.org
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org