Re: [Vala] "checked vs unchecked exceptions" && API design guidelines for Vala

[Frederik <scumm_fredo gmx net>]

Martin Olsson wrote:
> When Java was designed they went for checked exceptions. Later when the C#
> language was designed they went for unchecked exceptions. I'd like to
> understand better why one would go with either one. Also, does GObject
> give a bias in any direction? Should I be using "return codes" instead of
> "exceptions" like most of C programs tend to do? (after all Vala
> exceptions just wraps GError's and they are pretty different from Java or
> C# exceptions)
>
> I'm curious, why does Vala have checked exceptions? What was the rationale
> behind that design decision? I'm also curious about what API design
> guidelines are useful when designing API's in languages with checked
> exceptions.

To me it seems that the Vala design favours design-by-contract. Vala has
'requires' and 'ensures' keywords, parameters must be explicitly marked
as nullable and exceptions in Vala are part of the method contract, in
contrast to C#. Vala seems to emphasize correctness.

You might be interested in this interview with James Gosling on checked
exceptions in response to another interview with Anders Hejlsberg:
http://www.artima.com/intv/solid.html

> Below I've describe a concrete question I was thinking about earlier
> today. What is the best way to define a .peek() method on a stack class in
> Vala? I've tried to outline four different ways to do it but the most
> readable way is not possible in Vala because the lack of unchecked
> exceptions (I really don't want to add throws StackError to the
> process_stack method because it's valid to call this function with both
> empty stacks and non-empty stacks and thus the caller should not need to
> worry).

As far as I know exception handling is not intended for programming
errors such as division by zero, null dereference, index out-of-bounds,
etc. Exceptions should not be used for ordinary control flow, but for
unexpected failures / failures that the programmer can't predict (e.g.
I/O errors). If someone tries to peek an element from an empty stack
that's clearly a programming error. Your method should use assertions
for that and your stack API should provide means for the programmer to
query the state of his stack before if he's unsure about it, e.g. an
'is_empty ()' method.

> I think alternative #4 is the most readable, but Vala does not support
> writing code like that (no unchecked exceptions). So for now I think I
> will go with either #1 or #3. Even though #3 is shorter I think I like #1
> the most because it makes it more clear that empty stacks are handled as a
> special case. In #3 it's not obvious to an outside that trypeek() fails
> _only_ when the stack is empty, thus while reading this code it's hard for
> the outsider to know when which branch is taken. This is made easier in #1
> because it's clear that the assert(false) branch is not meant to be taken
> and if it is taken that would be obvious at runtime.

I'd go for Alternative #1.


Regards,

Frederik