Here are some requirements and additional description:
-- identify every error with unique code:
If error begins with unique prefix like MF or MYFACES, coder can at
first sight recognize framework which is the source of that
error/exception. For example Oracle DB throws ORA- or our company stuff
throws AR- prefixed codes.
Number after that prefix is unique identification of problem. Whole
construct can serve as key for query (for bugzilla, WIKi, ...) or as
simple abbreviation of the problem. Our programmers often say "999
happens" instead of "Unexpected failure of data happens" :)
-- text after error code:
Should not only describe what is wrong but also how to solve it.
-- details section:
This section can contain detailed description of problem. It can have
example of <f:ajax eventName="" />, hyperlink to javaDoc or VDL docs, or
a notice that IDEs mostly don't auto-complete this attribute.
In can look like overkill but those informations are required over and
over again. Especially if I hear the same question like "what is
eventName" and "give me an example" again .... (grrr)
Of course all information can be found elsewhere but to ease
development, every framework should be self-explanatory
This section can by also collapsable as is the part for component tree
already.
-- localization:
all human-readable text should be localizable because coders always read
and think faster in their mother language.
-- references section:
links to bugzilla, mail etc. Should be configurable, for example I want
provide link from error page to our internal bugzilla, not to myfaces
JIRA. Similar case for email address.
-- information about location of problem:
If Facelets VDL is used it is obvious to provide tag, column and line.
But we cannot limit it for facelets only. For example we have one
project that uses pure Java API for View creation and very complex
logic. Then if UIComponent.setId() throws new
IllegalArgumentException("component identifier must not be a zero-length
String"), is very hard to find the cause, if debugging is not available.
Here we can provide information about parent and path to component,
phase id etc.
Kočičák
Werner Punz píše v Út 11. 01. 2011 v 15:12 +0100:
> ++1
>
> Werner
>
>
> Am 10.01.11 20:06, schrieb Martin Koci:
> >
> > Hi,
> >
> > the most wanted feature which our coders want is more consistent and
> > human-readable error reporting and logging. Here is a example:
> >
> > If user specifies f:ajax without eventName for a component without
> > defaultEventName, myfaces throw a execption:
> >
> > Now (myfaces 2.0.3):
> > eventName could not be defined for f:ajax tag with no wrap mode.
> >
> >
> >
> > Improved (example only; from my copy of myfaces):
> >
> > MF0345: Your ajax tag does not specify eventName and component
> > com.foo.Bazz does not provide the default one. Please use one from
> > available: [change, blur, focus ...]";
> >
> > Tag location: XYZ.xhtml line 56 column 23,<f:ajax ..... />
> >
> > Component: id: componentId, class: com.foo.BazzInput, component type:
> > org.renderkit.Input
> >
> > ViewId: YYZ.xhml, located in file system
> > as: /tmp/deploy/weabpp/XYZ.xhtml
> >
> > PhaseId: RENDER_RESPONSE
> >
> > Details: ... a detailed description of this problem + suggestions,
> > example of code.
> >
> > References:
> > # Click for problem MF0345 in MYFACES knowledge database (hypertext
> > link)
> > # Contact your technology team : m...@to.me
> > # If you think this a bug report it: jira.project.org
> >
> >
> >
> >
> >
> >
> > What do you think about this idea?
> >
> > (I'll describe our requirements and what I found so far in next emails)
> >
> >
> > Regards,
> >
> > Kočičák
> >
> >
>
>
>
