I like that. One of the strengths of exceptions is that they are objects that can be manipulated outside of the try-catch-finally system. As you demonstrate, exceptions can be caught and then stuffed into a data structure: then they can be inspected later. It’s also possible to create an exception, store it in a data structure, and throw it at another point, which is useful for fault injection. Thanks for the example!

public class BusinessRuleSet
{
private Set rules = new HashSet();

public void addRule(BusinessRule rule)
{
rules.add(rule);
}

public void addRules(BusinessRuleSet ruleSet)
{
this.rules.addAll(ruleSet.rules);
}

public void applyTo(int recordIndex, Object subject) throws BusinessRulesFailedException
{
BusinessRulesFailedException errors = new BusinessRulesFailedException();

for ( Iterator iter = rules.iterator(); iter.hasNext(); )
{
try
{
((BusinessRule)iter.next()).applyTo(recordIndex, subject);
}
catch ( BusinessRuleException e )
{
errors.addError(e);
}
}

if ( errors.hasErrors() )
{
throw errors;
}
}
}

This is called via the following mechanism:

public void create(Collection records) throws BusinessRulesFailedException
{
// Preamble to test for user access and such.
…

int index = 0;
for(SomeType record: records)
{
createRules.applyTo(index, record);
index++;
}

// Call data layer to create the records.
…
}

This has been simplified for clarity.
Business rule objects evaluate a subject to test a particular business rule. If the object is in violation of that rule, it throws a BusinessRuleException.

The BusinessRuleSet object captures these exceptions and builds up a master BusinessRulesFailedException, which contains all of the rules that failed.

The BusinessRulesFailedException bubbles up out of the business layer, into the UI layer where the call to create() was made.

The UI catches this exception and then sifts through the individual exceptions contained within so that it can write out each error for each field in the data entry screen where a business error was triggered.

The exceptions themselves are unchecked (though declared). It is up to the programmer to decide what he wants to do, and where.

And for good reason too, as checked exceptions make it difficult to elegantly build higher order constructs.
For example, as a result of checked exceptions, many middleware products have to declare “throws Exception” (or wrap it in another exception) since they have NO idea what could be thrown from underneath. Now everything built on top of this has to declare “throws Exception” (or manually unwrap the middleware exception, which causes a big ugly mess of evaluation code just to figure out what happened). How useful is that?
The programmer using the product, however, will likely know what kind of exceptions will be coming out of it (or at least the ones he cares to deal with), and can handle them at the appropriate place.

The real tragedy of exceptions, checked or otherwise, is that a generation of programmers uses a convoluted syntactic construction for many situations that should be analysed, modeled, and handled as domain logic.

The web form in the article is an example: user data that does not ‘fit’ either format or value is not an exception situation, it is to be expected and handled explicitly.

There is absolutely nothing wrong with plain old return values and error codes. Exceptions should not be used for anything which could be anticipated in the domain logic of whatever layer or abstraction is currently applicable.

There are some legitimate situations where exceptions are the right way, but they are very very few indeed. It is only when the abstraction is broken: for example, device failure (not, emphatically not, network failure: if you’re doing anything with sockets or networks you damn well better expect to program retry and link down logic).

Using exceptions for domain logic is mental laziness disguised as a ‘modern’ technique.

@Matt’s got an interesting point. The Try-* pattern is appropriate for parsing text. Error handling based on return values gets into trouble quickly, however, if the effect of an error needs to propagate back up the call stack. I used the example I did because it was a simple example where catching an exception locally is appropriate — it’s not accidental that this coincides where cases where return values work.

@Kit has probably built bulk loaders that batch together groups of records into transactions for speed. I’ve seen this increase the speed of batch loads by factors of ten or more — that matters when loads take several hours! What he suggests is a premature optimization for many people, but necessary for large jobs.

I disagree with @Bob. In many cases, the right answer for many networking-based exceptions is to retry the “unit of work,” often with a delay. This is how e-mail delivery and large-scale webcrawlers work.

@Klosowski, I think encapsulation is a useful idea, but it’s also a partial truth, particularly when things go wrong. A “SubsystemAFailed” exception ~could~ be designed to give the caller useful semantics about what to do (answers for the eight questions) but it usually doesn’t. Reusing system-defined exceptions “does no harm” by avoiding information loss.

@paan, I think it’s more complicated than the effect that a language feature has on a particular programmer, but more the effect that a feature has on the ecosystem around a language. In particular, error handling is a place where local decisions have global consequences. Even if you were an absolute master at using checked exceptions, you’ll (i) be calling code written by people who are bad at it, and (ii) having your code called by people who are bad it. Since your code will have to deal with other people’s exceptions, and will throw exceptions into other people’s call stacks, you can’t escape from the problems checked exceptions create.

And if the programmer is have a hard time with his project because his programming language is a language that uses checked exception then either a)the language of choice for the project is not really suitable for the project or b)the programmer is not suitable/capable for the project

It’s like a php programmer that is complaining about the disadvantages of a loosely typed language.

A proper module should catch all exceptions in its own methods, and throw just the few (or one) exception, ModuleXyzzyBarfed. After all, if properly abstracted, it shouldn’t matter what specifically happened in this specific implementation—all the higher-level modules need to know is that this module failed.

No, all us “checked exceptions are bad” people believe it should be up to the programmer to decide when, where, and if he deals with a particular exception, and that he shouldn’t be hindered with extra boilerplate by people who think it necessary to force awareness of a particular exception.

Unchecked exceptions can handle distributed system issues perfectly well. This is irrelevant to the discussion.

When there’s a checked exception in an API it’s basically saying that something is likely to go wrong here. IOException happen when the disk fills up, SQLExceptions happen when the database goes down, etc. Just because that doesn’t happen most of the time doesn’t mean your program should just merrilly pretend it couldn’t happen and fail in an unexpected way when these conditions occur.