Maybe
nocatch { ... }
would make that case even clearer.
Am Dienstag, den 01.11.2011, 00:43 +0100 schrieb rastersoft:
> I don't think that
>
> try { ... }
>
> is a good idea, but
>
> try { ... };
>
> is. Just removing the catch can result in involuntary errors, but if you
> have to choose between a ";" or a "catch", the probability of
> "forgetting" it is greatly reduced.
>
> El 31/10/11 23:22, pancake escribió:
> > Hi
> >
> > On 31/10/2011, at 20:16, Aleksander Wabik<[email protected]> wrote:
> >
> >> My 2 pennies:
> >>
> >>> What about adding a code attribute like [IgnoreException] ? that would
> >>> perform better than trycatching
> >> It seems the most logical option to me. Vala is a language that allows
> >> ignoring exceptions, and (as far as I remember, it was a while ago when
> >> I was writing my vala code) it generates code printing warning about
> >> uncaught exception each time the exception is thrown, but not caught. I
> >> guess that we should have two solutions (not one or the other, but both
> >> implemented):
> >> - command line switch like -Wno-exceptions - it would disable all
> >> warnings about uncaught exceptions at the compile time, and in the
> >> non-debug builds it would also cause not generating code for printing
> >> exception information if the exception is thrown;
> > Looks an ugly solution to me. Some of those exceptions are important :)
> >
> >> - and some code attribute, that could be used in code, if the author is
> >> 100% sure that in this particular case exception will never be
> >> thrown, or that it can be ignored (compile and run time behaviour the
> >> same as above).
> >>
> > The option of allowing syntax like
> >
> > Try { ... }
> >
> > Without catch looks good to me, and probably cleaner than adding a code
> > attribute.
> >
> > But i dont know of any lang that does this already.. So maybe its
> > inconsistent
> >
> >
> >> Both these features have the advantage that no syntax changes in the
> >> language are needed.
> >>
> >> best regards,
> >>
> >>> On 31/10/2011, at 10:06, Xavier Bestel<[email protected]> wrote:
> >>>
> >>>> On Sun, 2011-10-30 at 11:04 -0400, Sam Wilson wrote:
> >>>>> Perhaps a better way to do this is like this:
> >>>>>
> >>>>> string[] test = new string[3];
> >>>>> for (int i = 0; i< 3; i++)
> >>>>> {
> >>>>> try
> >>>>> {
> >>>>> test[i] = kf.get_string(group, key);
> >>>>> }
> >>>>> catch (KeyFile.Error error)
> >>>>> {
> >>>>> // Do nothing
> >>>>> }
> >>>>> }
> >>>>> if (!test[0]&& !test[1]&& !test[3]) return false;
> >>>>>
> >>>>> What do you think?
> >>>> Won't that interrupt the execution flow, i.e. if the first
> >>>> g_key_file_get_string() throws an exception, the other ones won't be
> >>>> executed ?
> >>>>
> >>>> Xav
> >>>>
> >>>> _______________________________________________
> >>>> vala-list mailing list
> >>>> [email protected]
> >>>> http://mail.gnome.org/mailman/listinfo/vala-list
> >>>>
> >>> _______________________________________________
> >>> vala-list mailing list
> >>> [email protected]
> >>> http://mail.gnome.org/mailman/listinfo/vala-list
> >>
> >> --
> >> Mój klucz publiczny o identyfikatorze 1024D/E12C5A4C znajduje się na
> >> serwerze hkp://keys.gnupg.net
> >>
> >> My public key with signature 1024D/E12C5A4C is on the server
> >> hkp://keys.gnupg.net
> > _______________________________________________
> > vala-list mailing list
> > [email protected]
> > http://mail.gnome.org/mailman/listinfo/vala-list
>
_______________________________________________
vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
