"Barry Kelly" <✉eircom.net> wrote in message
news:✉4ax.com...

> I'd never suggest re-raising an exception if you didn't know where it is
> going to go. Of course you must be aware of where it's off to; whether
> to notify the user, or enter a logging system or whatever.

ok, there was just this standard 'raise;' part in each of your examples
above...

> Of course. This is what I mean by transactional programming. Roll-back
> or commit. Always leave the system in a valid state, assuming that
> exceptions can happen anywhere.

uhuh. so far so good.

> Woah! Exceptions are valuable:
>
> 1) They force error-handling; that is, they prevent code from blundering
> on regardless of errors. This, in my book, is a lot worse than simply
> crashing out.

No they don't force error handling, but they punish you mercilessly if
there's a hole in your code.

> 2) They unify error-handling into one mechanism. This is both useful
> (errors are self describing, are object oriented and thus can use
> polymorphism etc.) and not so useful (forces one size fits all policy).

I'll gladly concede 10 points to exceptions for that. <g>

> You seem to believe that the risk of letting a program continue in the
> face errors to be a virtue, if you are opposed to exceptions like this!

It *is* a virtue to survive errors. This is what fault tolerance is all
about.
In case of a real error (exposed fault, leading to true failure of a
module), I am *not* saying one should go on as if nothing happened, but
that one shall have the option of continuing with a graceful shutdown
and/or restart in a controlled manner, not just to get blown out of the
water. A failure in a software module *can* be survived if the module can
be verified as still healthy, or by restarting the concerned module.

>   b := nil;
>   a := TA.Create;
>   try
>     b := TB.Create;
>     // use a & b
>   finally
>     b.Free;
>     a.Free;
>   end;

OK, I know what you mean here.

> I feel like SHOUTING! That isn't what exceptions are about. Look:
>
>   a := TA.Create;
>   try
>     a.Stuff;
>   finally
>     a.Free;
>   end;
>
> Guess what! The finally part has access to local state!

I didn't (mean to?) say that this was not feasible. What I am saying is
that an error during "a.Stuff" transactions usually has no business being
resolved anywhere beyond the local context, except as a "last line of
defense". Often I hear exceptions being touted exactly for their
wonderful capability to bubble up to the application surface, *all by
themselves*!
This is the sort of exception behaviour I *don't* particularly like.
If every error situation you need to handle specifically (and locally)
requires its own try-finally clause, now that's the point where I say:
it's easier and cleaner to go by error codes. But that's just me I guess.

> I disagree; certainly, I don't know your exact domain, but fault
> tolerance isn't trivial. However, I don't think exceptions make it
> harder; in fact, I think they are better than other mechanisms, if only
> because they hit you on the nose if you try and ignore an error
> condition.

I don't like being hit on the nose. I'd rather have a quality oriented
tool tell me if my source code is vulnerable to unhandled error
conditions in certain spots. I never *try* to ignore error conditions
unless I'm sure I don't care about the outcome. In which case the further
progress of my application truly doesn't depend on it. (for example, say
I send something to a network printer. Due to e.g. network problems,
printing fails. My application's state is independent of success or
failure of the printing operation, so I don't care about the return code
or exception thus resulting. But an unhandled exception could kill my
application, even though I didn't care about it.

> I think such a tool would make for a lot of work when implementations
> change to use different mechanisms, resulting in different exceptions.

Well, the analysis has to be re-applied regularly of course.


Kristofer