On 17-Aug-12 14:10, Marco Leise wrote:
Am Fri, 17 Aug 2012 12:48:01 +0400
schrieb Dmitry Olshansky <dmitry.o...@gmail.com>:
[…]
Something like that. With ifs you query important properties about error
that allow you to pick the best recover decision. The whole propose of
flags is to unify only _important_ items for the _decision_ process and
hide useless variability (it still goes to message).
A comic-book example:
Top scientist breaks into Mr. President room and cries:
"We are doomed! Crystal oculator was miscalculated, all readings are
under 0.6543124312, helerium core just melted!"
Now does it mean it's time to evacuate promptly or instead give order to
isolate the secret lab and "end" this guy's project? Unless Mr.President
has a nice and long lookup table of all (pseudo) scientific terms he has
no clue.
I experimented with an enum that combines some error codes into a common action, like "retry
later", "authenticate", "give up", the list goes on.
Don't try to combine the _action_ into Exception. If there is definitive
action encoded (like re-try) then just do it. If there is uncertainty of
what exactly needs to be re-done (failure somewhere deeply nested) then
provide a hint on "state/possible recovery".
But for the networking case (and that's why I was asking for an example
of a broader application)
it is actually nice to have exceptions that read like an FAQ: Am I still
connected? Is the error temporary?
That's what I have shown (see transient & lost). Again exception
doesn't know _how_ (no action or it would do it itself) to restore, it
just provides nice hints to decision maker that indeed read as FAQ.
Now to the president: He might have a technical advisor, that translates the
scientists explanation.
Assume I'd implement an NNTP client.
The protocol allows for sudden state changes by the server, that would
cause unexpected errors.
(Reconfiguration of a running server.)
Should be part of library's job (technicians of said scientist).
It also allows for extensions,
that aside from some formalities can add functionality and error codes.
The president would be a programmer who is only interested in simple way to
read or post in newsgroups with the library hiding all the minutiae of
different error codes, detecting supported protocol versions or restoring state
on a reconnect (like which newsgroup was selected).
The technical advisor may want to make use of an extension for authentication
or searching the newsgroup,
so he needs to get at all the information and also create raw requests
with custom error handling.
First of all there are convenience wrappers and there is low-level API.
My proposition doesn't hurt this separation at all.
And here is where inheritance finally plays it's role.
The thing does nest:
NNTPException : NetworkExcpetion (lost, transient)
NNTPException contains more interesting & specific info (maybe even
straight error codes - why not if they are well documented?)
So high-level API is constructed from low-level, and it has some simple
hardwired logic but by the end of day it just passes through most
unexpected exceptions.
So president type of programmer just looks at it as NetworkException
(as he should, the higher you sit the less you see) and checks easy
flags/fields to make global recovery action.
The technical savvy type of programmer can use low-level API directly
and even catch NNTP exceptions if RFC error codes are needed (and there
could be genuine Network errors like connection lost).
I think WebDAV is one such extension of HTTP.
I way incompetent with NNTP. So take the above with a grain of salt.
P.S. For some reason Thunderbird flats your paragraphs into a very long
lines, split by hand sorry if inaccurate ;).
--
Olshansky Dmitry
