On Mon, Dec 8, 2008 at 2:15 PM, Jonathan S. Shapiro <[EMAIL PROTECTED]>wrote:
> On Mon, Dec 8, 2008 at 8:07 AM, Rodrigo Kumpera <[EMAIL PROTECTED]> wrote: > >> Declared exceptions in Java sucks because there is no language help to >> cope with proper capture and propagation. > > > Not so. I didn't do a good job describing the problem earlier, so let me > try again. There are several problems with declared exceptions. > > First, note that exception propagation cannot be inferred reliably. If f() > calls g(), and g() potentially raises ExAwkward, and f() does not include a > catch block at all, it does not follow that f() can raise ExAwkward. This is > a dependent typing problem. See the other thread on that subject. So two > issues here: (1) inference of exception propagation is not straightforward, > and (2) in the absence of dependent typing, declared exceptions inevitably > forces the declaration of exceptions *that cannot actually be thrown*. > [snip] > Inference of exceptions is a whole different problem that mandatory exception lists. Mandatory exceptions are specially useful at module boundaries, the 3 scenarios you describe pretty much figure out at such places. As I mentioned the usability pain of checked exceptions is due to having to declared them everywhere, something that can be fixed with proper inference, but one can think that exceptions should be part of interface, in bitc as capsules, signatures. I undestand that properly inferring the dynamic exceptions such a divide by zero that a piece of code can raise is probably non decidable, or will generate too much noise. But have you considered a compromise similar to what Java does, that only explicitly raised exceptions can be mandatory. Check exceptions can only ever be useful if the signal-to-noise is very low, otherwise developers will cheat. Thou I don't know any study to measure how better it is than providing a lint like schema.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
