From: Phil Muldoon <pmuldoon@redhat.com>
To: Sami Wagiaalla <swagiaal@redhat.com>
Cc: frysk@sourceware.org
Subject: Re: Frysk exceptions
Date: Wed, 14 Nov 2007 21:56:00 -0000 [thread overview]
Message-ID: <473B6EF3.2030307@redhat.com> (raw)
In-Reply-To: <473B67E7.3080902@redhat.com>
Sami Wagiaalla wrote:
> I have been meaning to write this for a while to clarify to my self
> the frysk strategy with respect to Exceptions and handling.
>
> These are my practices; please tell me if you agree or disagree:
>
> * All frysk exceptions are (should ?) be unchecked exceptions ie
> extend RunTimeException.
Right but they aren't. There are checked exceptions throughout the code
base from history. They will be fixed over time, but just a note that
they exist right now.
> * Exceptions should never ever be ignored.
One of the downsides of a unchecked exception is that one has to have a
good knowledge of the code-base to catch an unchecked exception. The
very nature of unchecked exceptions means they do not have to be
explicitly caught. That means all the usual ecj compiler checks will not
catch any leaks. Not sure what to do here, except that the top level
commands in fhpd/ui need to be very careful of intercepting said
unchecked exceptions. You can fix this by catching the big unchecked
exception superclass .....................
> So no catch(Exception e) statements, but
> catch(SymboleNotFoundException e).
This drills into the fact that one can expect to catch unchecked
exception foo, but rather unchecked exception bar happens instead which
is uncaught. Caution needs to be exercised that we are not falling into
the checked exception trap, even though the exception is unchecked. If
you start expecting callers to catch various different forms of
unchecked exceptions and creating a policy around that, then I think we
need a bit of a think on strategy. It creates a huge burden on the
caller of the api to have underlying knowledge of the code beyond that
api call. I constantly fall into the trap of writing code for myself,
but not to a wider unsuspecting audience. This is usually re-factored
out, but 5 years from now will user Joe know he has to catch several
different flavors of undeclared, unchecked exceptions?
> * Exceptions are better than returning null.
>
I cringe at NPEs in particular as they inform the user the programmer
was not diligent in checking the return of each function for sanity.
It's easy to do in chaining commands (ie foo().geBar().getFooBar()) but
I think from the user point of view it's pretty compelling evidence of
insufficient sanity checking.
Regards
Phil
next prev parent reply other threads:[~2007-11-14 21:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-14 21:26 Sami Wagiaalla
2007-11-14 21:56 ` Phil Muldoon [this message]
2007-11-14 22:13 ` Sami Wagiaalla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=473B6EF3.2030307@redhat.com \
--to=pmuldoon@redhat.com \
--cc=frysk@sourceware.org \
--cc=swagiaal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).