On 25 March 2011 12:45, Reinier Zwitserloot <[email protected]> wrote:
> On Friday, March 25, 2011 11:14:18 AM UTC+1, mP wrote: >> >> Perhaps just perhaps the problem is that heirarchy is both a grouping >> mechanism and a way to define checkness. Therefore if a marker was applied >> to an exception to denote whether it (the exception) was checked or >> unchecked ignoring whether it extended exception/runtime etc perhaps things >> would be better and more flexible.More hyperbole perhaps including a Checked >> and Unchecked marker interfaces do the trick. The way to solve a child >> implementing Unchecked if a parent was Checked would be that the compiler >> would respect the most derived implements. Since Annotations were not around >> its perhaps the best solution for this mess. >> >> Parent implements Checked // compiler treats Parent as checked. >> Child implemented Unchecked // compiler treats Child as unchecked >> > > This would not work all that well without abandoning the ability for > exceptions to be grouped based on type, which is also useful. If for example > IOEx was unchecked, but FNFEx was checked, and RemoteEx was unchecked (which > is what you propose), then declaring that you "throw IOException" is not > sufficient to force callers to acknowledge the FNFEx, assuming you throw it. > So what happens when I try this stunt: > > IOException ex = new FileNotFoundException(...); > throw ex; > > How'd the compiler figure this out? It would have to enforce a new standard > for exceptions and basically disable or severely curtail their object-ness, > for example by requiring all throw statements to be of the form "throw new > Something();" and not just "throw someVar;". This is a problem too, because > exceptions are also used as data objects that can be introspected to learn > more about what went wrong. > > If we must have checked exceptions, then why not just let the thrower determine "checkedness". You can throw anything you want, and you can put anything you want in a throws specification. If it's in the specification then the caller has to handle it, by simply rethrowing as an unchecked exception if necessary. This whole class hierarchy business just seems to be a guaranteed source of problems. -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
