On Aug 23, 11:39 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> A full and exhaustive treatise doesn't exist, but there are a few
> rules almost everyone can agree with, and yet these rules are not
> followed by the JDK, probably because we didn't know any better back
> then. i.e.:
> [...]
Thanks for the compact listing the best practices for using checked
exceptions!
> > The ten commandments are also very old posts
> Mixing religion into talk about programming is a very bad idea.
> But, I'll take your point that just because something is old does not
> mean it's wrong.
That's what I meant.
> So, why are you liking Joel's post so much? The only alternative he
> offers is something that boils down to maybees.
> [...]
> A Maybe is simply an alternate form of null:
I like his post because he points out that Exceptions are some form of
goto statements but being worse in the way that you often can't say
without detailed analysis from where the goto will be triggered.
Thanks for your explanation of the maybe - I have some methods where I
use the null result in case of error.
> > In the past (even before using Java) I have used a common accessible
> > error object (containing status information and error/warning message
> > lists) - a static one accessible from and for all levels within my
> > application.
> Oh, yeah, that'll go over real well with threading.
If I have a process that is spawn into several threads it is indeed
that at the end I want to have a single status if the whole process
was successful or not. - But I agree with you that in a lot of cases
you need separate handling for separate threads.
Yesterday when going to bed I spent still a longer time thinking about
the error handling in general. Peter painting the picture with the UML
chart with and without error handling was very impressive.
Maybe we should look at error handling from different point of views.
First, there is the very normal dummy user who don't have a clue on
what is there running in the background. Second there is a system
administrator who - if something goes wrong - could see whether there
might be a problem with the environment or with the configuration he
is responsible for. And then there is the developer who wants/needs
comprehensive detailed information if there is a doubt that an
upcoming error might be due to a bug.
The dummy user is usually overwhelmed if you present comprehensive
information (or a stack trace for example). He/She wants a simple
message - e.g. like Google Calender's "Ooops, some calenders could not
be loaded. Try again later." - I think basically every IOException
could result in such a final handling.
The administrator wants some more information, like if a host could
not be reached or name could not be resolved etc.
The developer is the only person interested in stack traces for
instance.
I think a solution for the different interests could be a proper
inheritance model of exceptions that you are using in your
applications. This means, if an exception occurs I can handle it using
the first parent exception to generate the "operation failed" thing
and for the developer log the exact detail exception that occurred. So
I could have some common PreCheckException (and children like
InputPreCheckException, ConfigurationPreCheckException and so on).
The second problem is the coding efficiency and readability. Within a
method depending on the exception some object variables might not be
set to a valid instance (if you have a longer try-block above and
handling just one parent exception). This may result in a lot of null-
checking necessary. A solution for this could be that the methods you
are calling should always return in a sane way (mostly just avoiding
null-pointer-exceptions) if they receive nulls as arguments.
Sample:
try
{
checkInputs(myTask);
checkEnvironment(myTask);
checkConfig(myTask);
con = openConnection(myTask);
}
catch (PreCheckException e)
{
doLoggingAndMessaging(e);
}
try
{
doCoreWork(con, myTask);
}
catch (ProcessingException e)
{
doLoggingAndMessaging(e);
}
closeConnection(con);
In that sample doCoreWork should fail if con is null or myTask is
missing some important data/status that it should have got during the
prechecks.
The closeConnection method on the other hand should not throw another
exception but silently finish if no (open) connection is given - just
as "well there is nothing to do for me".
Such a thing looks quite clean to me.
Just my - not verified - ideas.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
