Re: [Vala] try/catch concepts

[Jim Peters <jim uazu net>]

pancake wrote:
> I've been thinking a bit on this post.. and I agree with it that
> exception handling via try/catch hides the proper control flow of
> the program and can result in problematic situations.
>
>   https://groups.google.com/forum/#!topic/nodejs/1ESsssIxrUU/discussion
>
> as far as GObject follows a proper approach, and Vala just adds some
> sugar on top of it, we could add a way to manager exceptions in a
> more specific way. but I don't know which would be the right way to
> do it.
>
> I just want to share this thing with you and get some feedback about
> what you think it's ok for a language that aims to avoid common
> programming errors and keep the code easier for maintainance.

If a method returns an error code return value (instead of an
exception), to ignore it you just need to OMIT some code, i.e. it is
not immediately obvious that the error return was dropped.

With try/catch and exception propagation strictly checked by the
compiler, to ignore an error you have to add some very obvious code
catching the exception and doing nothing with it, i.e. you need to
make an effort to ignore it.  Otherwise the compiler complains and
forces you to declare the exception as thrown by the method.

Strict checked exception handling seems much safer to me.  I guess
JavaScript is completely non-strict, which means there is no benefit
to having exceptions because the compiler can't give any warnings or
errors.  According to the docs, Vala is strict but only gives compile
warnings, but this is good enough if you act on them.

Essentially exceptions and error returns are the same, the only
difference is the syntax and the checking done by the compiler.  A
syntax that makes coding omissions more obvious seems better to me,
even if it is a little more verbose.

(If libraries are badly designed and throw exceptions when they
shouldn't, that is another question, though.)


Talking about strictness, in general, I have found Vala not strict
enough, and I think this non-strictness is inherited from GLib.  Often
the generated code detects a fatal condition (e.g. NULL pointer) and
then just carries on or returns.  This usually means a crash much
later on in some unrelated code.  I would prefer a crash right away,
because it is obviously something not planned for, so the program
behaviour is undefined from then on (e.g. maybe I was counting on that
routine to initialise variables required later on, or to get a lock,
so loads of subtle errors could appear as a result -- and I've
actually had to debug several cases like this.)

This non-strictness just means more time spend debugging and cursing
Vala!  It depends on how resilient you want the code to be.  Java is
not perfect either: it really needs the '?' type flag like Vala has to
eliminate null-pointer-dereference errors at compile time rather than
run time, for example.  (I know it is not fully checked in Vala yet,
though.)

(There are two approaches to unplanned-for conditions: muddle on
through, potentially breaking design assumptions made by the
programmer, and leave bugs lurking for later, or fail immediately and
get the bug fixed.  Over several large projects I've learned that if
you're aiming for a solid bug-free application, the second approach is
the only way.  If you want a middle-quality application, then muddling
through may be okay, I guess.  Failing immediately means the bug gets
fixed quickly, and also means that testing is more worthwhile because
the bugs show up more easily.  To do this means a little bit of
discipline, but Java helps more than Vala in this case.)

To me, having syntax and compiler checks that make it harder to make
coding errors is helpful because that means a lot less time spent
debugging.  

If you want to use Vala as a scripting language (quick to code, little
discipline, few checks), I think that is supported because uncaught
exceptions generate compiler warnings instead of errors.

Jim

-- 
 Jim Peters                  (_)/=\~/_(_)                 jim uazu net
                          (_)  /=\  ~/_  (_)
 Uazú                  (_)    /=\    ~/_    (_)                http://
 in Peru            (_) ____ /=\ ____ ~/_ ____ (_)            uazu.net