But that code snippet is horrible; you should never catch an exception
and 'just log it' - ONLY the very top level should ever do that.
Secondly, if you do log-and-swallow, then whatever the heck you do,
don't continue with your method!
On Aug 24, 1:21 am, Martin Wildam <mwil...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
