Possible "throws" syntax

[Dmitry Olshansky]

On 17-Aug-12 14:10, Marco Leise wrote:
> Am Fri, 17 Aug 2012 12:48:01 +0400
> schrieb Dmitry Olshansky <dmitry.olsh at 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