ncellier at ifrance.com
Wed Nov 7 15:29:54 UTC 2007
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 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
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
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...
More information about the Squeak-dev