The Right Approach to Exceptions

[H. S. Teoh]

On Tue, Feb 21, 2012 at 09:32:35PM +0100, deadalnix wrote:
[...]
> So it doesn't help. Dulb subclasses of Exceptions are done mostly to
> be able to catch them. To avoid useless subclasses, we need a more
> precise way to catch Exception than the type only.
[...]

This is a good point.

Has anybody even considered, *why* does catch match by type? Is there a
good reason for that? Or is it just inherited from the rah rah days of
OOP where "everything is an object", so since exception is part of
everything, exception is an object, therefore we can just catch by
object type?

>From all the heated debate in this thread, it's clear that exceptions
don't map very well to a class hierarchy, at least not without points of
contention and what amounts to workarounds and hacks.

So I'm going to throw (har har) this very crazy and wild idea out there
and let's see if it's viable:

What if instead of catching by class, we catch by attribute matching?
So instead of writing:

	try { ... }
	catch(SomeExceptionType e) { ... }
	catch(SomeOtherExceptionType e) { ... }
	catch(YetAnotherSillyException e) { ... }

we write:

	try { ... }
	catch(e: exists!e.filename && e.failedOp is File.open) {
		// something
	}
	catch(e: e.is_transient && e.num_retries < 5) {
		// something else
	}
	// And why should we even need an exception object in the first
	// place?
	catch(time() >= oldtime+5000) {
		// This thing's been running for way too long, time to
		// do something drastic
	}

Flamesuit on! ;-)


T

-- 
Famous last words: I *think* this will work...