tim Rowledge <tim <at> rowledge.org> writes:

> 
> 
> On 6-Nov-07, at 8:46 PM, nicolas cellier wrote:
> >
> >
> > And Exception is more general. It can be handled in various ways.
> I won't argue with that but the practical problem I seem to keep  
> running into with exception handling is simply that nobody does it  
> very well.  I don't mean the actual mechanism of raising and catching  
> exceptions either - after all I did the VM and a fair bit of the image  
> work for exception handling in several Smalltalk systems, so obviously  
> that was Simply Magnificent 
> No, the bit that bothers me is how poorly exceptions get used.  I've  
> seen cases where every possible exception was being caught and ignored  
> 'to avoid presenting users with notifiers'.  I've seen people use them  
> to pass a value up to some other bit of code.  I've seen people do all  
> sorts of obscene things. Yuck.
> 
> Surely, somewhere there must be some documentation that explains how  
> to do it well? I'd love to be able to point culprits at a useful  
> learning example.
> 
> tim
> --
> tim Rowledge; tim <at> rowledge.org; http://www.rowledge.org/tim
> Did you hear about Christopher Robin Hood? He stole from the rich to  
> give to the Pooh
> 
> 


Concerning Exceptions in general, my only rules are:
- Rule 1: Don't use them unless it really helps.
- Rule 2: Don't forbid them neither!

You know the advantages:
1) factor error handling across a complex code hierarchy (several methods in
several classes).
It often beat alternative consisting to pass extra error-handling-arguments to a
bunch of messages and/or objects, or testing return codes at a lot of levels.
2) avoid same precondition tests repeated at lot of levels (optimistic
programming), keep only lowest level protected (usually a primitive).

You know the defaults:
1) don't protect inside a tight loop
2) in simple cases use a simple block argument
3) if handling logic become complex, better create a ErrorHandler object (rather
than the horror show you describe)

Compiler-Decoder would provide a complex test case for Exception framework.
OldCompiler does not use Exception.
A handler is passed, but is not known at every level of internal logic,
resulting in some error not being handled
(you get a debugger open on compiler internal logic,
which is not a direct path to your source code problem)...
Would Exception Help
- simplifying the code?
- enhance capabilities?
Maybe a subject for summer...



Concerning EndOfStream, it would be used mainly in some private Stream logic.
Eventually at a few place on client side (like factoring premature end of file
alarm), or maybe not at all.

I experiment a specific Stream extensions that would greatly benefit from it.
Existing code would not benefit from, unless rewritten.

Whether rule 2 implies:
- Rule 3: provide an Exception mechanism where it can prove usefull
is the core of this discussion.

Warning from Andreas are legitimate for sure: would it hurt?
1) It would not prevent [stream atEnd] nor [stream next == nil] constructs from
being used.
2) It might introduce a performance drop (whether noticeable or not in real
applications has to be proved).
3) It might introduce bugs and need strong/long tests phases in some production
image (IMO, using a Notification solves that, up to me to prove it). 

Maybe that's a second Nile-like subject for summer as Andreas suggested, though
i see it totally decoupled from traits (i did not make my opinion whether they
are good thing or not). But while at refactoring...


Nicolas