I disagree with the unchecked exceptions in Fantom language! Yes... Checked exceptions are not bad, they are actually essential for developing reliable software. The good or bad, lies on the realm of your application.

The problems are not in the checked exceptions, but in the way the language handles them. Java does it badly, because it only permits local checked exceptions. When you are developing software for a network for example, this behavior is quite acceptable, because a big part of the software is handling errors (timeouts and other errors) or in cases that error handling are critical (bank, spacecraft). But for web applications the common approach is to handle exceptions globally, log the stack trace and redirect to a error page, In this case, exceptions are more an aspect concern than a exception flux.

My propose is a trade of to put every one happy.

1. All exceptions are checked and announced in the method.
2. Exceptions must be always handled locally or globally.
3. The language must have some place (block of code) to handle exceptions globally.

Of course these changes have to be scrutinized to see if it mess with other language features.

I believe it's essential to, at least think about it for the sake of the future of reliable software!

EDIT: A small correction on this idea! Maybe pods are good places to put global handlers, or propagation handlers.

Another EDIT: One problem I see is checked exceptions messing with closures and functional programming, since you in principle must be able to throw an exception not announced in the method! This is an evidence that this feature has to be carefully analysed, but it doesn't men that can't be useful.

Man, are you spittin' into the wind!

Yes I know that this topic is dangerous! I also don't like the way Java handles checked exceptions (has I have said), I don't use it. But I acknowledge that checked exceptions have some value when building reliable software.

I'm not spitting into the wind because I know the problem, only exposing it in a different perspective.

It's not so much dangerous as it is already decided. Not to mention andy and brian probably value closures and functional programming over exceptions (either way). And I agree with that. I'm kinda split on the checked/unchecked exception thing. Personally I think that the current anti-checked mentality will be replaced by anti-unchecked mentality until we (re)discover some other technic (parameter based errors perhaps).

-1

I have yet to meet the checked exception that made my life easier.

Hu ? ..... NO

Hi shumy,

Certainly no hurt in trying to argue your position, as unpopular as it might be :-)

I think you will have a hard time convincing anyone that checked exceptions really improve reliability. No question there are better designs than Java's, but Java was the chance for it to be proved out in the field. And IMO it was a failure - checked exceptions are so painful to deal with that most people end up silently trapping them (which is worse for reliability) or wrapping them (which sucks for debugging). Plus checked exceptions don't fit the OO composition model - they create brittle interdependencies on implementation details (unless you wrap every exception).

Your observations about "global" versus "local" is a good one. In practice this is what I've found...

Global catch points such as a web request or UI command are natural places to catch every exception. Exceptions are amazing in that most decently designed applications pretty much anything can go wrong and its perfectly safe to catch the problem and keep chugging. This is why I think languages that eschew exceptions are simply insane.

Local problems tend to be things like parsing a number fails. One API that I truly hate is Java's URL constructor that throws a checked exception, despite the fact that this API is often used with string literals and such. In Fantom we have a pattern used all over place:

f := Float.fromStr(xxx)        // throws ParseErr on failure
f := Flaot.fromStr(xxx, false) // returns null on failure

Its just a design pattern, but I've found it works really well - if you expect it to work use the default checked version and you get a meaningful exception when it fails. If you think it might fail, pass false for checked and check for null.

Anyways, I don't think there is any chance that we'll ever add checked exceptions to Fantom. Too much of a breaking change, and I can't see that it would ever justify the value compared to 1000 other features we could do to boost productivity.

But please don't let that discourage more feedback :-)

Joel Sposky did have a good point about why exceptions in general are evil (checked to a lesser extent than unchecked). I did found his conclusion to use error codes a bit regressive or contra-productive.

Here is the link http://www.joelonsoftware.com/articles/Wrong.html

If banks and military defense organizations need stronger safety guarantees, those needs are exceptional (no pun intended), and the onus is on them to enforce them.

There's nothing stopping you from developing a lint tool to check exceptions. You can easily tell what exceptions can be thrown statically (in almost every case).

Also, flow control doesn't necessarily nest nicely into pods. Requiring pod-level exception handlers sounds like it would be a recipe for confusion.

If there's a new experimental way of realizing exceptions, Fantom isn't really the language for it.

This is why I think languages that eschew exceptions are simply insane.

Hear hear.

Joel Spolsky...

Joel has had a good idea once or twice, but by and large my heuristic is "If Joel thinks it's a good idea, DON'T EVER DO IT." He's just been wrong so many times, in so many ways.

his conclusion to use error codes

Perfect case in point.

Not that I'm opinionated or anything :-)

I also have a heuristic Things happen what the heck. Hell I'll try anything once (language without exceptions is Ok). But again I agree Fantom is "Boring by Design"™ and this feature doesn't seem that interesting either.

to brian: I also hate the URL constructor in java. I generally don't agree with checked exception in constructors. But this is just one more case where java uses checked exceptions in a wrong way.

I have found some interesting research by Microsoft: http://research.microsoft.com/en-us/um/people/leino/papers/krml135.pdf

Apart from all the validation spec (that I also have mentioned in design by contract post), I like the pattern of using a try<method name> for methods that have checked exceptions. Inverting this pattern, I imagine a language where you could convert checked exceptions to unchecked invoking the method in a different way. Using it like:

//checked version

File xFile = new File("file.txt");
try{
  OutputStream xStrem = xFile.open(); 
} catch(NoFileException ex) {
  ... present a message to user ...
}

//unchecked version, only open if exists...

File xFile = new File("file.txt");
if(xFile.exits()){
  OutputStream xStrem = checked xFile.open(); 
}

The reflection system is also a good place to convert exceptions.

to tactics: Developing tools for checked exceptions means that you have at least to declare the exceptions in your method.

We can invert the use of the new keyword (converting unchecked to checked exception). Anyway the method has to declare the exception.

EDIT: maybe the correct way to deal with exceptions will be:

File xFile = new File("file.txt");
check {
  OutputStream xStrem = try xFile.open(); 
} catch(NoFileException ex) {
  ... present a message to user ...
}

note the check and try keywords.

EDIT: Every one has an opinion of using/not using checked exceptions, my point is more like of a review, change it to a better way.