Brett Connor <[EMAIL PROTECTED]> wrote on 09/09/2004 02:03:00 PM:
> [EMAIL PROTECTED] wrote:
>
> >Brett Connor <[EMAIL PROTECTED]> wrote on 09/09/2004 12:22:39 PM:
> >
> >
> <bigger snip>
>
>
> Yep. The error code in whatever form it is in (depending on your company
> standards and convesions) can be used to directly determine what went
> wrong, technically, in the same way that we all recognize HTTP 404, but
> no text is present. Are you familiar with Oracle? That's a nice example
> to use. Every Oracle product has a namespace (actually it's a fairly
> pervasive product code). Every possible message / error condition has a
> code within that namespace, and can be looked up in one of the reams of
> manuals or references. For example ORA-1403 (IIRC) means "no rows found
> matching the criteria" - coming from the database. PLS-1403 will mean
> something quite different, ORA-22146 will be different again, etc. The
> exception in this case would contain "ORA" and 22146 - comprising
> between them a key, and perhaps also some parameters relating to the
> message or error. It will _never_ contain message text. The action or
> any other appropriate presentation layer builds whatever will be shown
> to the user. Typically for me this is handled by common code called by
> actions, rich clients etc, ie not tied to a web app.
>
This is basically what I'm driving for just hitting a few potholes on the
way.
> Note that at this presentation layer I would not expect to be dealing
> with Java exceptions in this way, by now they're either related to the
> use case in some way that the user will understand, or they're something
> seriously wrong in the system. This is where it becomes tricky to keep
> on the straight and narrow I find, I want the user meaningful context to
> be available in or from the exception, the presention code reporting the
> exception should not have to try and guess what the user was doing from
> their POV when things went wrong. Messages like "XML parse error:
> element <frog> missing required attribute X" doesn't mean anything to me
> - I thought I was ordering a book - what the hell is a frog doing
> there?! Even a call stack is not going to help me at this point. This is
> a constantly evolving area for me, each project I refine things a little
> further based on what didn't work quite as I'd hoped, and try to
> consistenly use the scheme, so that every exception thrown out of the
> business layer has all of the context required for a dumb but pretty
> presentation.
>
What I'm going through right now. Time to refactor - again.
Thanks for you time and help. At least I know now I'm on the right path.
> Brett Connor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
