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

[Thomas Chust <chust web de>]

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.
> [...]

Hello,

I think this is mainly a matter of taste, like it is the case for many
programming language design decisions.

If a language has only unchecked exceptions, it means that the language
designer thought they should normally be used only to signal error cases
detected at runtime that cannot always be handled. Checked exceptions on
the other hand can also be thought of as auxiliary return paths.

A more pragmatic reason why C# has unchecked exceptions is probably the
experience with Java where the combination of several APIs especially in
the presence of callback interfaces often leads to an absurd amount of
useless work to ensure correct exception handling -- checked exceptions
are boxed in unchecked ones or checked ones of a different type and
unwrapped at a different stack level. With unchecked exceptions this
kind of problem never occurs.

> [...]
> 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)
> [...]

Since GError handling is accessible from C without problems and is a far
more flexible error handling scheme than using plain integer return
codes or global variables, I would always recommend to use Vala's
exception mechanism and not to reinvent the wheel in a less comfortable
and more error prone way.

> [...]
> I'm curious, why does Vala have checked exceptions? What was the rationale
> behind that design decision?
> [...]

The simple answer to this question is that unchecked exceptions cannot
be modelled on top of GError handling well, since GErrors can only be
propagated by functions that know about them. Hence checked exceptions
are the most logical choice for Vala.

> [...]
> 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?
> [...]

My personal opinion is that no matter what type of exceptions is used,
your alternative #3 is the most readable and logical way of doing it,
since peeking at an empty stack is not really an error of any kind. A
peek operation is precisely intended to check whether something is empty
and to possibly also return an element if it is not. This should be
represented by an appropriate return type, for example with a boolean
return and an output parameter or with a polymorphic return type that
can either hold a value or represent the absence of one.

However, if you absolutely want to use exceptions for this kind of task,
my personal opinion is that an unchecked exception would be a totally
inappropriate choice here, since the absence of a value in a peek
operation is not a hard runtime error, rather it is one of the expected
outcomes of this operation and should therefore always be processed.

These consideration don't apply to a regular pop or get operation, of
course.

cu,
Thomas


-- 
When C++ is your hammer, every problem looks like your thumb.