[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

What about the signal-to-noise aspect? I find that to be annoying with
logging and the only sane reason to use AOP. However since I have an
issue with complexity and library creep, I prefer to simply have a
NetBeans plugin suppress the font color of logging statements. In the
perfect world, the IDE would be capable of masking these aspects - not
totally unlike what Lombok is attempting.

/Casper

On 24 Aug., 14:05, Peter Becker  wrote:
> Martin Wildam wrote:
>
> [...]
>
> > 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).
>
> I think sometimes the same exception can be required to be looked at in
> different ways. While the user should always get some high-level "we are
> sorry" message, the admin/developer distinction is not necessarily
> nicely along a hierarchy you describe. In fact some of the lowest
> exceptions could be of a nature that administrators have to resolve.
>
> Things get even more complicated if the boundaries are blurry. I've seen
> that many times with smaller projects and I believe it is still common
> at Amazon: the developers are also administrators. There can be quite
> different logging setups depending on your organizational structure,
> auditing needs and other aspects. That's where external logging
> configurations come into play.
>
> And don't forget that there are at least two dimensions: the hierarchy
> and the chaining. I tend to chain exceptions through the abstraction
> layers while using the hierarchies to model different level of detail
> within a layer.
>
> In some way I like the idea of a higher level error reporting system
> where the user interface is not just plain text but allows drilling down
> into the information, ideally with structure data in the exceptions.
> I've seen such systems used in various places (although not with much
> structured data). In some way the Windows error log is one, but I have
> also seen logging handlers that log into a full-blown database or a
> ticket system. The problem is that you really want your logging to be
> easy and reliable, which those system often are not. But even in text
> format you can gain a lot by making sure your exception message is
> written well and with enough information to identify the real issue
> without wading through stack traces (as a developer) or guru meditation
> (everyone).
>
> > 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
> 

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Martin Wildam wrote:

[...]
> 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).
>   
I think sometimes the same exception can be required to be looked at in 
different ways. While the user should always get some high-level "we are 
sorry" message, the admin/developer distinction is not necessarily 
nicely along a hierarchy you describe. In fact some of the lowest 
exceptions could be of a nature that administrators have to resolve.

Things get even more complicated if the boundaries are blurry. I've seen 
that many times with smaller projects and I believe it is still common 
at Amazon: the developers are also administrators. There can be quite 
different logging setups depending on your organizational structure, 
auditing needs and other aspects. That's where external logging 
configurations come into play.

And don't forget that there are at least two dimensions: the hierarchy 
and the chaining. I tend to chain exceptions through the abstraction 
layers while using the hierarchies to model different level of detail 
within a layer.

In some way I like the idea of a higher level error reporting system 
where the user interface is not just plain text but allows drilling down 
into the information, ideally with structure data in the exceptions. 
I've seen such systems used in various places (although not with much 
structured data). In some way the Windows error log is one, but I have 
also seen logging handlers that log into a full-blown database or a 
ticket system. The problem is that you really want your logging to be 
easy and reliable, which those system often are not. But even in text 
format you can gain a lot by making sure your exception message is 
written well and with enough information to identify the real issue 
without wading through stack traces (as a developer) or guru meditation 
(everyone).
> 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
This approach can help sometimes, in particular if you can model your 
system in such a way that the prechecked-objects have only safe methods 
(modulo the usual candidates you can hardly avoid such as running out of 
memory). But I don't think this is always feasible, e.g. if you do 
processing on a database you either have to have a lot of memory to 
buffer data or you have to live with the fact t

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

On Aug 24, 9:14 am, Reinier Zwitserloot  wrote:
> 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.

Sorry, I should have given additional example lines in there like

doRepairAttempts();
setTaskStatus(myTask);

and so on.


> Secondly, if you do log-and-swallow, then whatever the heck you do,
> don't continue with your method!

The problem of doing this in a finally-block means that you start
getting a lot of nested blocks - I tried to find an escape from that.
- But, well, it was just an idea trying to produce very clear and
readable code and at the same time get useful output (for user, admin
and developer).

Error handling should be done correctly, code should be resistant to
bugs and should be readable, context should be kept, ... - yes, error
handling is difficult.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

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  wrote:
> On Aug 23, 11:39 am, Reinier Zwitserloot  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.
-

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

On Aug 23, 11:39 am, Reinier Zwitserloot  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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

On Aug 23, 12:52 am, Martin Wildam  wrote:
>
> In reality programmers could live without exceptions for many, many
> years. ;-)

We all coded assembly too. You're flipping the argument around now,
Martin: Just because something is old, it's true.

That's just as logically invalid as 'Something is old, therefore its
false'.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

On Aug 23, 12:36 am, Martin Wildam  wrote:
>
> The question is: How really to use them right? I think this is a
> desired result of this discussion. :-]
>

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.:

 - Don't throw a bazillion checked exceptions. (Reflection API, I'm
looking at you).

 - Don't create situations where methods are declared to throw
exceptions that you know, _FOR SURE_, and which a sufficiently
advanced compiler could even sort out for you, couldn't possibly
happen. Stupidest example of this: the AccessException that most
reflection methods throw. If you've called .setAccessible() before, it
is DEFINED as COULD NOT POSSIBLY happen. This is ridiculous usage of a
checked exception. The same happens with new String(byteArray,
"UTF-8") - the JLS definition again states that an
UnsupportedEncodingException could not possibly happen, and the same
happens yet again with filter input/outputstreams working on
ByteArrayInput/OutputStream - The declared IOExceptions just cannot
happen, ever. (Unless the filter operation can itself generate
IOExceptions, which makes the problem even worse: You can no longer
tell from the API of a FilterIn/OutputStream if it can be a source of
checked exceptions, or if it is only passing through the exceptions of
the stream it's wrapping.

 - Make sure your interfaces throw a plenty broad exception type.
failing at this game: Servlet API, java.lang.Runnable.

 - If you're going to use checked exceptions, make sure they are
borderline useful, and not just a general flag as: Oh, operation
failed, and I'm not going to tell you how. Exceptions of that sort
should be unchecked because in 75% of all cases you just want the
thing to move right back up the stack until a centralized 'something
went wrong' handler, which will be catching everything. Failing at
this: SQLException, though recent JDBC versions are working on
improving the situation.

> 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. However, who was attacking Joel's post as old? I've
been relentlessly bashing Joel's opinion on exceptions because it's
WRONG, not because it's old. It was wrong when he wrote it. It's still
wrong now.

>
> Never heard of the "Maybe" type - but I am pretty sure that a "Maybe"
> would be the last thing I would like having to deal with.

So, why are you liking Joel's post so much? The only alternative he
offers is something that boils down to maybees. Well, or ints as error
code, but I take it we all think that a horrible idea, right? (And,
technically, error codes as ints is a maybe as well. Just a really,
really, _really_ bad, non-namespaced, unreadable version of it)

A Maybe is simply an alternate form of null: You can ask a Maybe if it
has a value, and you can ask a Maybe for the value. If it didn't have
a value, then that would throw an exception. (Uh, I see a chicken and
egg problem here...) - though the more likely type of object to use
here would be an Either. An Either holds either an object of type A,
or of type B, and it has a method where you can ask which is which.
Again, what would happen if you then asked for the wrong one?

The 4 methods are usually 'isLeft()', 'isRight()', 'left()' and 'right
()'. Both Maybe and Either can preserve typing via generics. I'm not
saying its a good idea. I'm saying its the only way to make Joel's "no
exceptions" story work.

>
> 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.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

It's not out of band, Peter - this stuff happens, in real life, even
if you never explicitly accepted the burden of responsibility by e.g.
using @SneakyThrows. Just mixing class files compiled against
different versions of the same code base is enough to get there. Thus,
you *CANNOT* just swallow exceptions. I was not referring to your 'Ex'
as standing specifically for java.lang.Exception - it doesn't matter
what exception class it stands for. Swallowing an exception
automatically behind the scenes is not acceptable. At the very least
wrap it up (not my preferred solution, certainly, but better than
swallowing it).

On Aug 22, 11:53 am, Peter Becker  wrote:
> I think I might have caused some confusion by being too lazy: Ex is
> meant to be a particular checked exception, not a shorthand for "Exception".
>
> If you are referring to your sneaky throws: I consider them out of
> scope. There are many ways to subvert Java code, particularly if
> reflection is allowed. If anyone throws a checked exception in code that
> was explicitly designed not to throw it (after all that is what the
> safe/unsafe distinction is for), then so be it. Java is not strong
> enough to stop someone with that attitude from breaking things.
>
>   Peter
>
>
>
> Reinier Zwitserloot wrote:
> > Peter, your code sample is very much broken - exceptions are just
> > silently swallowed in the safe version. Sure, you declared that the
> > exception can't happen, but as I've mentioned a few times already,
> > because checked exceptions aren't enforced on the JVM level, they can
> > occur at _any_ time. Therefore, occasionally, such code would swallow
> > an exception. No good.
>
> > I'm fairly sure that turning every java method into BGGA-style
> > "throws" containing generics is going to be just as annoying, if not
> > far worse, than the current situation. The problem with checked
> > exceptions is that all implementations so far suck far worse than they
> > help. I remain convinced that java's checked exception system with an
> > explicit command to get around the checked exception system is the
> > most practical (though it is of course not the most elegant).
>
> > On Aug 21, 11:43 am, Peter Becker  wrote:
>
> >> As I said: in cases where you want to have a version of your code where
> >> the exception bubbles up and one where it doesn't you'll get the
> >> duplication. I think that is usually a bad idea, although I must admit
> >> the wrapper case you describe is an exception since the layer is the
> >> same. I don't see that problem spread too far, though.
>
> >> If your code is really that big, I'd even consider this:
>
> >> public class UnsafeWrapper implements UnsafeInterface {
> >>     protected UnsafeInterface orig;
> >>     ...
> >>     public doAction() throws Ex {
> >>          ...
> >>          orig.doAction();
> >>          
> >>     }
>
> >> }
>
> >> public class SafeWrapper implements SafeInterface {
> >>     ...
> >>     public doAction() {
> >>        ...
> >>        try {
> >>            orig.doAction(); // call on UnsafeWrapper.doAction()
> >>        } catch(Ex e) {
> >>            // won't happen
> >>        }
> >>     }
>
> >> }
>
> >> Not very elegant, but avoids major duplication.
>
> >> I believe that with union types the whole problem would disappear since
> >> the subtyping would allow using generics to create the different
> >> versions. As long as exceptions are not part of the type signature it
> >> won't happen in Java.
>
> >>    Peter
>
> >> Reinier Zwitserloot wrote:
>
> >>> Peter, I still don't see how that'll avoid code duplication.
>
> >>> Let's say, for argument's sake, that a FilterInputStream's read()
> >>> method contains 4 pages of complex code. This code calls back into the
> >>> filtered stream's read method loads of times. How would we avoid
> >>> duplicating these 4 pages if we want 2 types of FilterInputStream: One
> >>> that wraps a Safe InputStream and does not throw IOException, and one
> >>> that wraps an unsafe InputStream and does throw IOException.
>
> >>> On Aug 20, 9:36 am, Peter Becker  wrote:
>
>  Here you go (three files):
>
>  = test/Unsafe.java==
>  package test;
>
>  import java.io.IOException;
>
>  public interface Unsafe {
>      void method() throws IOException;
>
>  }
>
>  = test/Safe.java ==
>  package test;
>
>  public interface Safe extends Unsafe {
>      void method();
>
>  }
>
>  =test/Test.java===
>  package test;
>
>  import java.io.IOException;
>
>  public class Test {
>      class UnsafeImpl implements Unsafe {
>          @Override
>          public void method() throws IOException {
>              throw new IOException(); // ok
>          }
>      };
>
>      class SafeImpl implements Safe {
>          @Override
>          public void method() {
>              // can't throw here
>          }
>      };
>
>      void method1(

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Casper Bang wrote:
> On 23 Aug., 01:25, Peter Becker  wrote:
>   
>> Someone should probably write a nice book talking only about error
>> handling, the different ways to propagate errors (special return values,
>> checked exceptions, unchecked exceptions, union types) and the different
>> ways to deal with them. A nice chapter on logging strategies would be
>> good, too. Maybe one on the errors you can't handle (stuff such as
>> external errors, infinite loops, infinite recursion, resource leaks).
>> Does anyone know of such a book or volunteer? :-)
>> 
>
> Well if you read best-practice/state-of-the-art books like Clean Code,
> Code Complete, The Pragmatic Programmer etc. you already get most of
> that. But this is the complex world of Java, I have no doubt we could
> see a book on logging frameworks and strategies. That's when I think
> we need simplicity back so that it won't just be the top 10% reading
> books, that will be capable of producing quality code.
>   
I think error handling strategies transcends languages. The book you 
listed do that, too -- but even these books tend to focus on the 
positive cases.

Error handling seems to be the one case hardly anyone gets right. 
Examples for beginners tend to ignore the whole question. Quite often 
you really don't need to (it can be quite acceptable that your program 
crashes in rare cases), but if your system is mission or even life 
critical you suddenly get into a realm that usually no one talks about. 
Or at least no in those books I've read, which could well be my fault.

  Peter

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

On 23 Aug., 01:25, Peter Becker  wrote:
> Someone should probably write a nice book talking only about error
> handling, the different ways to propagate errors (special return values,
> checked exceptions, unchecked exceptions, union types) and the different
> ways to deal with them. A nice chapter on logging strategies would be
> good, too. Maybe one on the errors you can't handle (stuff such as
> external errors, infinite loops, infinite recursion, resource leaks).
> Does anyone know of such a book or volunteer? :-)

Well if you read best-practice/state-of-the-art books like Clean Code,
Code Complete, The Pragmatic Programmer etc. you already get most of
that. But this is the complex world of Java, I have no doubt we could
see a book on logging frameworks and strategies. That's when I think
we need simplicity back so that it won't just be the top 10% reading
books, that will be capable of producing quality code.

/Casper
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

On Aug 22, 12:02 pm, Peter Becker  wrote:
> But I agree with you that the alternatives aren't necessarily better.

Yep, everything has two sides (at least) :-(


> Somehow error handling is never easy. Just take one of these nice
> graphical displays of code execution (UML, workflows) and add the error
> handling in. Particularly in workflows your nice and simple graph
> suddenly turns into a mess.

Well said, well said - very good example - and a reason why most
people prefer assuming that everything is going well. ;-)


> The same is true on the code level: code
> that is pretty straightforward for the normal case can quickly turn into
> a mess once error handling is added, no matter what system of error
> handling you use.

And either no matter what programming language.


> One note: I think you could probably write a system where most common
> technical errors are handled via return values, but you would need to
> have a lot of unions/eithers. That approach is quite comparable to the
> checked exceptions (I have done this comparison the other way around
> before), but the control flow is quite different.

In reality programmers could live without exceptions for many, many
years. ;-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Martin Wildam wrote:
> On Aug 22, 7:23 am, Peter Becker  wrote:
>   
>> While I'm still arguing for checked exceptions, I'm not 100% convinced
>> their good yet either. But nearly every argument I see why they are bad
>> is about how they are used badly, with the conclusion of some intrinsic
>> badness.
>> 
>
> I agree with you. - But since (at least my opinion) exceptions are
> either used badly in some of the core Java APIs from Sun the question
> is really, how to get people - especially beginners - to understand
> how they are used correctly.
>   
Now that is a good question to ask.

Unfortunately when teaching about exceptions you will encounter some 
major poblems:
1) the first encounter with exceptions will be most likely the JDK, i.e. 
a bad example (and beginner's tend to think the JDK must have the best 
design ever)
2) to deal with exceptions you need to do the wrong things sometimes 
unless you avoid the JDK somehow
3) there doesn't seem to be much agreement on how to do it right in the 
community
4) most people who have experience claim that checked exceptions are 
intrinsically broken (IMO invalidly)

To me it feels like a big case of SNAFU, sustained by Sun's 
unwillingness to do anything that breaks backwards-compatibility. I 
think the only thing you can do to teach someone something decent about 
exceptions is to teach them different error handling approaches in the 
abstract, and make them aware that in many scenarios error handling can 
be the most complicated aspect of your code.

Someone should probably write a nice book talking only about error 
handling, the different ways to propagate errors (special return values, 
checked exceptions, unchecked exceptions, union types) and the different 
ways to deal with them. A nice chapter on logging strategies would be 
good, too. Maybe one on the errors you can't handle (stuff such as 
external errors, infinite loops, infinite recursion, resource leaks). 
Does anyone know of such a book or volunteer? :-)

  Peter

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

On Aug 22, 7:23 am, Peter Becker  wrote:
> While I'm still arguing for checked exceptions, I'm not 100% convinced
> their good yet either. But nearly every argument I see why they are bad
> is about how they are used badly, with the conclusion of some intrinsic
> badness.

I agree with you. - But since (at least my opinion) exceptions are
either used badly in some of the core Java APIs from Sun the question
is really, how to get people - especially beginners - to understand
how they are used correctly.


> Martin's recent argument about the confusing flow wasn't too bad, but
> interestingly applies to all exceptions, not just the checked flavor.

Oh yes, this applies even to the unchecked exceptions. What I like
with the checked exceptions is that I can't forget that I have to
decide what to do with them - for return codes I could forget to
handle them (even if an experienced developer - especially an
experienced Windows API or C++ programmer should not have a problem
with this ;-) ).
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

On Aug 21, 4:46 pm, B Smith-Mannschott  wrote:
> Checked exceptions *are* a failed experiment.

My first experience and after reading Joel's post I was thinking that
but previous posters convinced me that this is not necessarily true -
but I think there lies some truth also in your comparison with
communism.

BTW: I find the checked exceptions more useful than the unchecked
exceptions (for using in my own code).


> Some have argued that there's nothing wrong with checked exceptions,
> per se, it's just that people don't use them right.

The question is: How really to use them right? I think this is a
desired result of this discussion. :-]


> Joel's article, I can't really agree with, though it's a pretty old
> post. Exceptions as an alternate form a control flow have their place.

The ten commandments are also very old posts - information or thoughts
do not necessarily become less important with increasing age. ;-) - I
cannot say that I completely agree with everything in that post, but
the point that completely fits my experience is the decreased
readability.


> I wish Java had a good way of dealing with partial functions (i.e.
> functions that can't return a sensible value for all possible inputs).
> The only options we seem to have are: throw an exception or return
> null. Java's null is a mess. (Though sometimes the Null Object Pattern
> can help here.) Languages with a Maybe type (e.g. Scala) are
> appealing.

Never heard of the "Maybe" type - but I am pretty sure that a "Maybe"
would be the last thing I would like having to deal with. I like in
Python that a function can return multiple values, but something
similar can be achieved in Java returning objects. Imagine to return
an object that contains a return value + your data. However, if you
have very different return types you would need many different new
classes encapsulating all the combinations.

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. So my functions can return a value or null and if they
produce an error they tell this separately. An advantage is that
whoever interested can investigate current error status and a
disadvantage is that you have to be careful when to reset error
status. But I have used this method quite successful for many years
prior using Java. I have started implementing something similar for my
Java projects and I think I can improve this method further.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

After initially disagreeing completely I can see a point in that 
exceptions break the normal control flow and can thus cause surprising 
behavior. But I agree with you that the alternatives aren't necessarily 
better.

Somehow error handling is never easy. Just take one of these nice 
graphical displays of code execution (UML, workflows) and add the error 
handling in. Particularly in workflows your nice and simple graph 
suddenly turns into a mess. The same is true on the code level: code 
that is pretty straightforward for the normal case can quickly turn into 
a mess once error handling is added, no matter what system of error 
handling you use.

One note: I think you could probably write a system where most common 
technical errors are handled via return values, but you would need to 
have a lot of unions/eithers. That approach is quite comparable to the 
checked exceptions (I have done this comparison the other way around 
before), but the control flow is quite different. The File class in Java 
stands out so much since it is different, but it might just work 
somewhere else.

  Peter



Reinier Zwitserloot wrote:
> I can't let this horse puckey about 'exceptions are less readable'
> stand. It's hogwash.
>
> Consider that any operation, anywhere in the entirety of your java
> source base, can throw just about any exception. Not just
> theoretically, but practically: You can get an OutOfMemoryError, or a
> ClassNotFoundError, for example. Actually trying to shove these status
> conditions into some sort of return object that tracks exactly what
> went right and what went wrong is *PHENOMENALLY* more boilerplate than
> even java's verbose checked exception system. I take it as axiomatic
> that returning an integer that holds an error code is utterly insane.
>
> At best you can make an argument that you ought to keep exceptions for
> the very exceptional, and to push the line between 'exceptional' and
> 'alternative exit condition' as far to the exceptional side as you
> can; e.g all file operations ought to return a FileOperationResult
> object.
>
> But, I put it to you: How happy would you really be with such an API?
> Because it exists, folks. java.io.File. Instead of throwing
> exceptions, it returns booleans. And it's so hated, its getting
> replaced in java 7. It's been tried, it's failed miserably. You'd have
> to return an object that states the exact problem that actually
> occurred, and, at that point, aren't you just writing the equivalent
> of:
>
> public IOException mkdir() {}?
>
> whether the IOException is returned normally (or, more likely, in the
> case of a method that also needs to return some actual data, as an
> Either and you'd have to query the Either to figure out what happened
> - d'oh) or 'returned' via the exception mechanism is relatively
> speaking a very small point. A much bigger point is that you just
> can't get around the notion that you NEED some sort of exception
> system to handle the truly exceptional - unless we'd all prefer going
> back to the 'core dumped' days, and that there's a real need to have
> semi-exceptional conditions that you'd like, by default, to walk up
> the stack quite a bit before being handled.
>
> Here, simple example: You write a servlet, and something untoward
> happens - say, a database issue (SQLException). In plenty of
> situations you don't want your servlet to handle it - you want that
> problem to walk up the stack, back to the servlet container that knows
> to return a 500, log something, and maybe try to notify an
> administrator. It would be hopeless if you had to rely on the serlvet
> to pass through problems. It would also make changing APIs to add new
> flavours of the exceptional much more problematic, and as
> theoretically sound it seems to say: But public APIs shouldn't ever
> change! - that's not very practical. The exceptional stuff is the
> first thing APIs are likely to change, exactly because it is so
> closely related to implementation details.
>
>
> Joel was dead wrong.
>
>
> On Aug 21, 3:40 pm, Martin Wildam  wrote:
>   
>> On Aug 21, 2:07 pm, Peter Becker  wrote:
>>
>> 
>>> I take the point that it is possible to make code harder to read using
>>> exceptions in a way that is not possible without. I must admit I didn't
>>> really think it through when I read Joel's blog post.
>>>   
>> I think the reduced readability is the core disadvantage of using
>> Exceptions.
>> And I think that it is easier to create buggy code with exceptions -
>> especially for beginners.
>> (I know that most of those doing Java do it since a long while but
>> they get older and junger people must somehow follow them).
>>
>> 
>>> There is the opposite danger, though: ignoring a return value. Since
>>> C-like languages allow functions to be called as statements, it is
>>> pretty easy to just ignore the fact that there is an error code
>>> returned. Checked exceptions force you to deal with the issue.
>>>   
>> Whether it is an 

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

I think I might have caused some confusion by being too lazy: Ex is 
meant to be a particular checked exception, not a shorthand for "Exception".

If you are referring to your sneaky throws: I consider them out of 
scope. There are many ways to subvert Java code, particularly if 
reflection is allowed. If anyone throws a checked exception in code that 
was explicitly designed not to throw it (after all that is what the 
safe/unsafe distinction is for), then so be it. Java is not strong 
enough to stop someone with that attitude from breaking things.

  Peter



Reinier Zwitserloot wrote:
> Peter, your code sample is very much broken - exceptions are just
> silently swallowed in the safe version. Sure, you declared that the
> exception can't happen, but as I've mentioned a few times already,
> because checked exceptions aren't enforced on the JVM level, they can
> occur at _any_ time. Therefore, occasionally, such code would swallow
> an exception. No good.
>
> I'm fairly sure that turning every java method into BGGA-style
> "throws" containing generics is going to be just as annoying, if not
> far worse, than the current situation. The problem with checked
> exceptions is that all implementations so far suck far worse than they
> help. I remain convinced that java's checked exception system with an
> explicit command to get around the checked exception system is the
> most practical (though it is of course not the most elegant).
>
>
> On Aug 21, 11:43 am, Peter Becker  wrote:
>   
>> As I said: in cases where you want to have a version of your code where
>> the exception bubbles up and one where it doesn't you'll get the
>> duplication. I think that is usually a bad idea, although I must admit
>> the wrapper case you describe is an exception since the layer is the
>> same. I don't see that problem spread too far, though.
>>
>> If your code is really that big, I'd even consider this:
>>
>> public class UnsafeWrapper implements UnsafeInterface {
>> protected UnsafeInterface orig;
>> ...
>> public doAction() throws Ex {
>>  ...
>>  orig.doAction();
>>  
>> }
>>
>> }
>>
>> public class SafeWrapper implements SafeInterface {
>> ...
>> public doAction() {
>>...
>>try {
>>orig.doAction(); // call on UnsafeWrapper.doAction()
>>} catch(Ex e) {
>>// won't happen
>>}
>> }
>>
>> }
>>
>> Not very elegant, but avoids major duplication.
>>
>> I believe that with union types the whole problem would disappear since
>> the subtyping would allow using generics to create the different
>> versions. As long as exceptions are not part of the type signature it
>> won't happen in Java.
>>
>>Peter
>>
>>
>>
>> Reinier Zwitserloot wrote:
>> 
>>> Peter, I still don't see how that'll avoid code duplication.
>>>   
>>> Let's say, for argument's sake, that a FilterInputStream's read()
>>> method contains 4 pages of complex code. This code calls back into the
>>> filtered stream's read method loads of times. How would we avoid
>>> duplicating these 4 pages if we want 2 types of FilterInputStream: One
>>> that wraps a Safe InputStream and does not throw IOException, and one
>>> that wraps an unsafe InputStream and does throw IOException.
>>>   
>>> On Aug 20, 9:36 am, Peter Becker  wrote:
>>>   
 Here you go (three files):
 
 = test/Unsafe.java==
 package test;
 
 import java.io.IOException;
 
 public interface Unsafe {
 void method() throws IOException;
 
 }
 
 = test/Safe.java ==
 package test;
 
 public interface Safe extends Unsafe {
 void method();
 
 }
 
 =test/Test.java===
 package test;
 
 import java.io.IOException;
 
 public class Test {
 class UnsafeImpl implements Unsafe {
 @Override
 public void method() throws IOException {
 throw new IOException(); // ok
 }
 };
 
 class SafeImpl implements Safe {
 @Override
 public void method() {
 // can't throw here
 }
 };
 
 void method1(Unsafe unsafe) {
 unsafe.method(); // error, need to deal with exception
 }
 
 void method2(Safe safe) {
 safe.method(); // ok
 }
 
 }
 
 ==
 
 The one trick is to realize that the safe version is actually the more
 specific one. If you think of the exception in terms of the type union
 (not accurate, but a decent analogy), then Unsafe.method() returns
 void|IOException while Safe.method() returns void, which is a more
 specific type, thus the return types are co-variant.
 
 More generally you can argue

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

Peter, your code sample is very much broken - exceptions are just
silently swallowed in the safe version. Sure, you declared that the
exception can't happen, but as I've mentioned a few times already,
because checked exceptions aren't enforced on the JVM level, they can
occur at _any_ time. Therefore, occasionally, such code would swallow
an exception. No good.

I'm fairly sure that turning every java method into BGGA-style
"throws" containing generics is going to be just as annoying, if not
far worse, than the current situation. The problem with checked
exceptions is that all implementations so far suck far worse than they
help. I remain convinced that java's checked exception system with an
explicit command to get around the checked exception system is the
most practical (though it is of course not the most elegant).


On Aug 21, 11:43 am, Peter Becker  wrote:
> As I said: in cases where you want to have a version of your code where
> the exception bubbles up and one where it doesn't you'll get the
> duplication. I think that is usually a bad idea, although I must admit
> the wrapper case you describe is an exception since the layer is the
> same. I don't see that problem spread too far, though.
>
> If your code is really that big, I'd even consider this:
>
> public class UnsafeWrapper implements UnsafeInterface {
>     protected UnsafeInterface orig;
>     ...
>     public doAction() throws Ex {
>          ...
>          orig.doAction();
>          
>     }
>
> }
>
> public class SafeWrapper implements SafeInterface {
>     ...
>     public doAction() {
>        ...
>        try {
>            orig.doAction(); // call on UnsafeWrapper.doAction()
>        } catch(Ex e) {
>            // won't happen
>        }
>     }
>
> }
>
> Not very elegant, but avoids major duplication.
>
> I believe that with union types the whole problem would disappear since
> the subtyping would allow using generics to create the different
> versions. As long as exceptions are not part of the type signature it
> won't happen in Java.
>
>    Peter
>
>
>
> Reinier Zwitserloot wrote:
> > Peter, I still don't see how that'll avoid code duplication.
>
> > Let's say, for argument's sake, that a FilterInputStream's read()
> > method contains 4 pages of complex code. This code calls back into the
> > filtered stream's read method loads of times. How would we avoid
> > duplicating these 4 pages if we want 2 types of FilterInputStream: One
> > that wraps a Safe InputStream and does not throw IOException, and one
> > that wraps an unsafe InputStream and does throw IOException.
>
> > On Aug 20, 9:36 am, Peter Becker  wrote:
>
> >> Here you go (three files):
>
> >> = test/Unsafe.java==
> >> package test;
>
> >> import java.io.IOException;
>
> >> public interface Unsafe {
> >>     void method() throws IOException;
>
> >> }
>
> >> = test/Safe.java ==
> >> package test;
>
> >> public interface Safe extends Unsafe {
> >>     void method();
>
> >> }
>
> >> =test/Test.java===
> >> package test;
>
> >> import java.io.IOException;
>
> >> public class Test {
> >>     class UnsafeImpl implements Unsafe {
> >>         @Override
> >>         public void method() throws IOException {
> >>             throw new IOException(); // ok
> >>         }
> >>     };
>
> >>     class SafeImpl implements Safe {
> >>         @Override
> >>         public void method() {
> >>             // can't throw here
> >>         }
> >>     };
>
> >>     void method1(Unsafe unsafe) {
> >>         unsafe.method(); // error, need to deal with exception
> >>     }
>
> >>     void method2(Safe safe) {
> >>         safe.method(); // ok
> >>     }
>
> >> }
>
> >> ==
>
> >> The one trick is to realize that the safe version is actually the more
> >> specific one. If you think of the exception in terms of the type union
> >> (not accurate, but a decent analogy), then Unsafe.method() returns
> >> void|IOException while Safe.method() returns void, which is a more
> >> specific type, thus the return types are co-variant.
>
> >> More generally you can argue that Safe.method() makes stronger
> >> guarantees about its behavior than Unsafe.method(), so subtyping is
> >> legal. Apart from the one marked position the code above is legal Java.
>
> >>   Peter
>
> >> Reinier Zwitserloot wrote:
>
> >>> On Aug 20, 12:21 am, Peter Becker  wrote:
>
>  No implementation would be duplicated, the safe version could be a
>  subtype of the unsafe one. Not too many interfaces will face that
>  problem. To me it seems much better than not distinguishing.
>
> >>> Can you show me how this would work?
>
> >>> I have a hard time seeing how you can do that without (oh, the irony),
> >>> employing some sort of sneakythrow mechanism.
>
> >>> I guess we will have to agree to disagree here, but I'm fairly sure
> >>> the idealism lost in allowing sneakythrow is minor, whereas the amount
> >>> of pain you can solve is sizable. (in practice, due to widespread bad
> >>> AP

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

I can't let this horse puckey about 'exceptions are less readable'
stand. It's hogwash.

Consider that any operation, anywhere in the entirety of your java
source base, can throw just about any exception. Not just
theoretically, but practically: You can get an OutOfMemoryError, or a
ClassNotFoundError, for example. Actually trying to shove these status
conditions into some sort of return object that tracks exactly what
went right and what went wrong is *PHENOMENALLY* more boilerplate than
even java's verbose checked exception system. I take it as axiomatic
that returning an integer that holds an error code is utterly insane.

At best you can make an argument that you ought to keep exceptions for
the very exceptional, and to push the line between 'exceptional' and
'alternative exit condition' as far to the exceptional side as you
can; e.g all file operations ought to return a FileOperationResult
object.

But, I put it to you: How happy would you really be with such an API?
Because it exists, folks. java.io.File. Instead of throwing
exceptions, it returns booleans. And it's so hated, its getting
replaced in java 7. It's been tried, it's failed miserably. You'd have
to return an object that states the exact problem that actually
occurred, and, at that point, aren't you just writing the equivalent
of:

public IOException mkdir() {}?

whether the IOException is returned normally (or, more likely, in the
case of a method that also needs to return some actual data, as an
Either and you'd have to query the Either to figure out what happened
- d'oh) or 'returned' via the exception mechanism is relatively
speaking a very small point. A much bigger point is that you just
can't get around the notion that you NEED some sort of exception
system to handle the truly exceptional - unless we'd all prefer going
back to the 'core dumped' days, and that there's a real need to have
semi-exceptional conditions that you'd like, by default, to walk up
the stack quite a bit before being handled.

Here, simple example: You write a servlet, and something untoward
happens - say, a database issue (SQLException). In plenty of
situations you don't want your servlet to handle it - you want that
problem to walk up the stack, back to the servlet container that knows
to return a 500, log something, and maybe try to notify an
administrator. It would be hopeless if you had to rely on the serlvet
to pass through problems. It would also make changing APIs to add new
flavours of the exceptional much more problematic, and as
theoretically sound it seems to say: But public APIs shouldn't ever
change! - that's not very practical. The exceptional stuff is the
first thing APIs are likely to change, exactly because it is so
closely related to implementation details.


Joel was dead wrong.


On Aug 21, 3:40 pm, Martin Wildam  wrote:
> On Aug 21, 2:07 pm, Peter Becker  wrote:
>
> > I take the point that it is possible to make code harder to read using
> > exceptions in a way that is not possible without. I must admit I didn't
> > really think it through when I read Joel's blog post.
>
> I think the reduced readability is the core disadvantage of using
> Exceptions.
> And I think that it is easier to create buggy code with exceptions -
> especially for beginners.
> (I know that most of those doing Java do it since a long while but
> they get older and junger people must somehow follow them).
>
> > There is the opposite danger, though: ignoring a return value. Since
> > C-like languages allow functions to be called as statements, it is
> > pretty easy to just ignore the fact that there is an error code
> > returned. Checked exceptions force you to deal with the issue.
>
> Whether it is an exception or a return code you always can drop it or
> deal with it. When I use a method like openFile or something the first
> thing automatically is to look for a return code.
>
> > Of course that problem could also be fixed by disallowing calling
> > functions as statements, which I think would be a good idea not just for
> > this reason.
>
> I would loose then the option to ignore the result which may make
> sense (e.g. loading an optional configuration file).
> People want closures, annotations and all the like but then I should
> get limited how to use a simple method?
>
> Best regards, Martin.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Christian Catchpole]

Yeah, I still agree with the theory.  Maybe if tools always,
automatically updated your throws declarations and there were special
rules about interfaces and overridden methods.  Maybe then things
would be different.

On Aug 22, 3:23 pm, Peter Becker  wrote:
> B Smith-Mannschott wrote:
>
> [...]> Some have argued that there's nothing wrong with checked exceptions,
> > per se, it's just that people don't use them right. This is akin to
> > acknowledging that every attempt to practice communism on a national
> > level has lead to a  repressive police state, and yet still insisting
> > that it would be a great way to run a country, if only people would do
> > it right!
>
> > A "good" idea that can only be implemented badly, isn't a good idea.
>
> The point I'm trying to make is that many people come to that conclusion
> after one failed experiment. Not very scientific, particularly since
> that experiment was executed pretty badly IMO.
>
> While I'm still arguing for checked exceptions, I'm not 100% convinced
> their good yet either. But nearly every argument I see why they are bad
> is about how they are used badly, with the conclusion of some intrinsic
> badness. This is highly illogical, my personal conclusion is we need
> more experiments. Or some arguments why they are intrinsically bad.
>
> Martin's recent argument about the confusing flow wasn't too bad, but
> interestingly applies to all exceptions, not just the checked flavor.
>
>   Peter
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

B Smith-Mannschott wrote:
[...]
> Some have argued that there's nothing wrong with checked exceptions,
> per se, it's just that people don't use them right. This is akin to
> acknowledging that every attempt to practice communism on a national
> level has lead to a  repressive police state, and yet still insisting
> that it would be a great way to run a country, if only people would do
> it right!
>
> A "good" idea that can only be implemented badly, isn't a good idea.
The point I'm trying to make is that many people come to that conclusion 
after one failed experiment. Not very scientific, particularly since 
that experiment was executed pretty badly IMO.

While I'm still arguing for checked exceptions, I'm not 100% convinced 
their good yet either. But nearly every argument I see why they are bad 
is about how they are used badly, with the conclusion of some intrinsic 
badness. This is highly illogical, my personal conclusion is we need 
more experiments. Or some arguments why they are intrinsically bad.

Martin's recent argument about the confusing flow wasn't too bad, but 
interestingly applies to all exceptions, not just the checked flavor.

  Peter

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Martin Wildam wrote:
> On Aug 21, 2:07 pm, Peter Becker  wrote:
>   
>> I take the point that it is possible to make code harder to read using
>> exceptions in a way that is not possible without. I must admit I didn't
>> really think it through when I read Joel's blog post.
>> 
>
> I think the reduced readability is the core disadvantage of using
> Exceptions.
> And I think that it is easier to create buggy code with exceptions -
> especially for beginners.
> (I know that most of those doing Java do it since a long while but
> they get older and junger people must somehow follow them).
>   
In my experience beginners hardly ever think of the exceptional cases to 
begin with ;-)

The reduced readability is IMO not really applicable either, since I 
don't see many beginners writing complex code in a neat fashion like 
your example. And an experienced Java programmer shouldn't write the big 
bit of code where the exception just bubbles out.

>> There is the opposite danger, though: ignoring a return value. Since
>> C-like languages allow functions to be called as statements, it is
>> pretty easy to just ignore the fact that there is an error code
>> returned. Checked exceptions force you to deal with the issue.
>> 
>
> Whether it is an exception or a return code you always can drop it or
> deal with it. When I use a method like openFile or something the first
> thing automatically is to look for a return code.
>   
But is that true for your average Joe Java?
>   
>> Of course that problem could also be fixed by disallowing calling
>> functions as statements, which I think would be a good idea not just for
>> this reason.
>> 
>
> I would loose then the option to ignore the result which may make
> sense (e.g. loading an optional configuration file).
> People want closures, annotations and all the like but then I should
> get limited how to use a simple method?
>   
Anything that has a return value that can be ignored seems suspicious to 
me. Arguably in Javaland you couldn't enforce such rule without some 
option of ignoring it in places, but I'd quite like at least a compiler 
warning with matching @SuppressWarning.

For me an ideal system would have functions that are SEF and procedures 
that never return anything. But I'm a bit of a purist sometimes.

  Peter

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[B Smith-Mannschott]

Hi Possefolks,

I've been following both of the Exception-handling mega-threads and
have some opinions too, though unlikely original given the length of
the thread.

Checked exceptions *are* a failed experiment.

I thought they were a good idea when I first ran into them, but the
reality is quite different. In practice they cause details of the
implementation to leak into the method signatures. The way to avoid
that is, of course, to provide exceptions of the correct abstraction
level at each module boundary and wrap, wrap, wrap. Welcome,
stacktrace-from-hell.

Some have argued that there's nothing wrong with checked exceptions,
per se, it's just that people don't use them right. This is akin to
acknowledging that every attempt to practice communism on a national
level has lead to a  repressive police state, and yet still insisting
that it would be a great way to run a country, if only people would do
it right!

A "good" idea that can only be implemented badly, isn't a good idea.


Joel's article, I can't really agree with, though it's a pretty old
post. Exceptions as an alternate form a control flow have their place.

I've seen the sorts of contortions they go through in the Subversion
code base (ANSI-C) to do error handling. Basically they've co-opted
the normal function return for exception handling. APIs all return
some kind of svn_error_t structure. It's a solution that's positively
screaming for an exception mechanism. And yet... I don't think this
would have helped them much since in a language without automatic
resource management the sort of unstructured control flow exceptions
bring must really be hell.


I wish Java had a good way of dealing with partial functions (i.e.
functions that can't return a sensible value for all possible inputs).
The only options we seem to have are: throw an exception or return
null. Java's null is a mess. (Though sometimes the Null Object Pattern
can help here.) Languages with a Maybe type (e.g. Scala) are
appealing.


In my more perverse moments, I imagine exceptions seem a little like
INTERCAL's COMEFROM statement.

// Ben

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

On Aug 21, 2:33 pm, Casper Bang  wrote:
> However exceptions are meant
> to be used for exceptional cases and not a replacement for proper
> factored condition checking down the primary path.

Oh, this is a very good point! - I see that both can make sense
depending of the case - if a method checks some state or is really
running into an error. Thanks for pointing that out!


> Another problem
> with Joel's view is that of context, if you can only signal an error
> code, you'll have to resort to some shared/mutable place for further
> context.

I think the problem of context you also have when dealing with an
exception on the low level. Context is known most likely only by some
parent caller but on the other hand the parent caller often does not
have any clue about how some functionality has been implemented on the
low level and hence either does not really know what happens.

The parent just can say that "the operation failed, try again" - which
is often a good option for displaying to the user (my applications
used to return a lot of information to allow quickly locating the core
issue, however that was too overwhelming for the user and so I created
the simple AND detailed information offering the details at click). To
combine simple and detailed information (linked together) often did
not work well for me in the past when processing multiple items with
inner complexity due to using different other 3rd party libraries and
so on.

Finding the right context in error/warning case is a challenge in
general I think - with or without exceptions and no matter which
language used.


> Well they force you to acknowledge them, but they don't really do
> anything else and as such can provide a false sense of security (can
> be swallowed or logged).

Indeed, however it has a little more "reminder-character" with the
checked exceptions.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

On Aug 21, 2:07 pm, Peter Becker  wrote:
> I take the point that it is possible to make code harder to read using
> exceptions in a way that is not possible without. I must admit I didn't
> really think it through when I read Joel's blog post.

I think the reduced readability is the core disadvantage of using
Exceptions.
And I think that it is easier to create buggy code with exceptions -
especially for beginners.
(I know that most of those doing Java do it since a long while but
they get older and junger people must somehow follow them).


> There is the opposite danger, though: ignoring a return value. Since
> C-like languages allow functions to be called as statements, it is
> pretty easy to just ignore the fact that there is an error code
> returned. Checked exceptions force you to deal with the issue.

Whether it is an exception or a return code you always can drop it or
deal with it. When I use a method like openFile or something the first
thing automatically is to look for a return code.


> Of course that problem could also be fixed by disallowing calling
> functions as statements, which I think would be a good idea not just for
> this reason.

I would loose then the option to ignore the result which may make
sense (e.g. loading an optional configuration file).
People want closures, annotations and all the like but then I should
get limited how to use a simple method?

Best regards, Martin.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

On 21 Aug., 15:50, Martin Wildam  wrote:
> I think the problem of context you also have when dealing with an
> exception on the low level. Context is known most likely only by some
> parent caller but on the other hand the parent caller often does not
> have any clue about how some functionality has been implemented on the
> low level and hence either does not really know what happens.

Oh with context, I was more thinking about supplying additional
information from down below where the exception got thrown. Think of
an input field of a some complex UI, say an IDE's property editor. If
you supply invalid input, the component's model (or observers of it)
can raise a PropertyVetoException and supply the original
PropertyChangeEvent as a member.

When you catch this PropertyVetoException higher up, you can use the
PropertyChangeEvent member to see which property you're dealing with,
what the value was originally and what the user tried to enter. So you
show an error dialog with this information as well as pointing out
constraints of the particular input in question.

Conceptually, you pass new context backwards on the existing call
stack. This can be abused of course, primarily concern being leaking
abstractions. However it beats having to deal with a tangled
decentralized web of conditionals and shared variables to get to the
same context.

/Casper
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

> I take the point that it is possible to make code harder to read using
> exceptions in a way that is not possible without. I must admit I didn't
> really think it through when I read Joel's blog post.

Joel seems to think of exceptions as mere alternative return points
and in that goto light, he has a point. However exceptions are meant
to be used for exceptional cases and not a replacement for proper
factored condition checking down the primary path. Another problem
with Joel's view is that of context, if you can only signal an error
code, you'll have to resort to some shared/mutable place for further
context.

> There is the opposite danger, though: ignoring a return value. Since
> C-like languages allow functions to be called as statements, it is
> pretty easy to just ignore the fact that there is an error code
> returned. Checked exceptions force you to deal with the issue.

Well they force you to acknowledge them, but they don't really do
anything else and as such can provide a false sense of security (can
be swallowed or logged). At least with a non-checked, an unhandled
problem would just bubble up to the surface and be trapped in some
high-level place around the message pump.

/Casper

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

I can follow your argument to some extent, but wouldn't the equivalent, 
exception-based code have a try/catch block per if(goAhead)? I agree 
that this would create code that is more verbose, but otherwise it seems 
equivalent.

I take the point that it is possible to make code harder to read using 
exceptions in a way that is not possible without. I must admit I didn't 
really think it through when I read Joel's blog post.

There is the opposite danger, though: ignoring a return value. Since 
C-like languages allow functions to be called as statements, it is 
pretty easy to just ignore the fact that there is an error code 
returned. Checked exceptions force you to deal with the issue.

Of course that problem could also be fixed by disallowing calling 
functions as statements, which I think would be a good idea not just for 
this reason.

  Peter



Martin Wildam wrote:
> On Aug 21, 11:33 am, Peter Becker  wrote:
>   
>> Number one clearly does not apply to checked exceptions, number two
>> applies to returning values, too. Of course you could assign a value and
>> follow the approach of having a single return statement at the end, but
>> I never understood why the resulting code should be any easier.
>> 
>
> Both, "They are invisible in the source code." and "They create too
> many possible exit points" target the "hidden" jumps in code. While
> debugging Java code with heavy use of exceptions I found out plenty of
> possibilities in code where some code lines were or were not executed
> depending on the exceptions occurring. In reality I would need to
> write plenty of nested finally blocks to ensure correct handling of
> all steps.
>
> Let me draw a constructed extreme opposite example not using
> exceptions (before you comment on this example, know that I already
> understood that this is no good practice):
>
> boolean goAhead = true;
> if (!checkEdits()) goAhead = false;
> if (!checkConfig()) goAhead = false;
> if (!openDestinationFile()) goAhead = false;
>
> //Prechecks failed so we leave
> if (!goAhead) return goAhead;
>
> //Start with regular work
> if (goAhead)
> {
>//We do some first transaction
>startTransaction();
>doSomeSaveWorkThatCannotFail();
>if (!doSomeTransactionWork()) goAhead = false;
> }
>
> if (goAhead)
> {
>   doSomeMoreSaveWorkThatCannotFail();
>   yetAnotherBunchOfOperations();
>   if (!saveSomeDataOrDoSomethingElse()) goAhead = false;
> }
>
> if (goAhead)
> commitTransaction();
> else
> rollBackTransaction();
>
> The difference here is that you have no ACCIDENTALLY LINE SKIPPING.
>
> If you use instead something like this:
>
> try
> {
> checkEdits();
> checkConfig();
> openDestinationFile();
> }
> catch (Exception e)
> {
> throw new PreCheckException();
> }
>
> try
> {
>startTransaction();
>doSomeSaveWorkThatCannotFail();
>doSomeTransactionWork();
>doSomeMoreSaveWorkThatCannotFail();
>yetAnotherBunchOfOperations();
>saveSomeDataOrDoSomethingElse();
>commitTransaction();
> }
> catch (SomeBusinessLogicException e)
> {
> //Where did I get my Exception from? Until which line the above
> has been processed?
> rollBackTransaction();
> }
> catch (SomeTransactionException e)
> {
> //Where did I get my Exception from? Until which line the above
> has been processed?
> rollBackTransaction();
> }
> catch (IOException e)
> {
> //Again we need the rollback
> rollBackTransaction();
> }
>
> For the first part it makes no big difference - a little less work
> with using exceptions.
> In the second part you can't easily see (without examing javadoc of
> the called methods) which lines could have produced the exception.
> Encapsulating every single operation with try-catch is clearly not an
> option as it produces much more boilerplate (if several lines could
> throw the same exceptions) than using return codes. An advantage of
> using return codes is having a clear information about the overall
> status of the whole operation "automatically".
>
> BUT: I think the handling of the different exceptions can be solved
> with throwing your own Exception type instead of returning a
> resultCode. And I think to remember something like this recommended by
> Josh Bloch in his book "Effective Java" (just don't remember which
> item and I don't have the book at hand). The only thing is the need of
> an extra Class for your application exception(s). Hey, and you can
> throw an exception that contains either a return code - there you
> would have everything. - Remaining issue is only that in some cases I
> simply don't care of the return codes and I can decide this in the
> parent method. But this can be solved using Unchecked Exceptions
> instead of checked exceptions. - And this is the point where I love to
> have the option of using checked or unchecked exceptions.
>
> Thank you guys - with your help I got cleared that up.
> >
>   


--~--~-~--~~~---~--~~
You received this messag

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

On Aug 21, 11:33 am, Peter Becker  wrote:
> Number one clearly does not apply to checked exceptions, number two
> applies to returning values, too. Of course you could assign a value and
> follow the approach of having a single return statement at the end, but
> I never understood why the resulting code should be any easier.

Both, "They are invisible in the source code." and "They create too
many possible exit points" target the "hidden" jumps in code. While
debugging Java code with heavy use of exceptions I found out plenty of
possibilities in code where some code lines were or were not executed
depending on the exceptions occurring. In reality I would need to
write plenty of nested finally blocks to ensure correct handling of
all steps.

Let me draw a constructed extreme opposite example not using
exceptions (before you comment on this example, know that I already
understood that this is no good practice):

boolean goAhead = true;
if (!checkEdits()) goAhead = false;
if (!checkConfig()) goAhead = false;
if (!openDestinationFile()) goAhead = false;

//Prechecks failed so we leave
if (!goAhead) return goAhead;

//Start with regular work
if (goAhead)
{
   //We do some first transaction
   startTransaction();
   doSomeSaveWorkThatCannotFail();
   if (!doSomeTransactionWork()) goAhead = false;
}

if (goAhead)
{
  doSomeMoreSaveWorkThatCannotFail();
  yetAnotherBunchOfOperations();
  if (!saveSomeDataOrDoSomethingElse()) goAhead = false;
}

if (goAhead)
commitTransaction();
else
rollBackTransaction();

The difference here is that you have no ACCIDENTALLY LINE SKIPPING.

If you use instead something like this:

try
{
checkEdits();
checkConfig();
openDestinationFile();
}
catch (Exception e)
{
throw new PreCheckException();
}

try
{
   startTransaction();
   doSomeSaveWorkThatCannotFail();
   doSomeTransactionWork();
   doSomeMoreSaveWorkThatCannotFail();
   yetAnotherBunchOfOperations();
   saveSomeDataOrDoSomethingElse();
   commitTransaction();
}
catch (SomeBusinessLogicException e)
{
//Where did I get my Exception from? Until which line the above
has been processed?
rollBackTransaction();
}
catch (SomeTransactionException e)
{
//Where did I get my Exception from? Until which line the above
has been processed?
rollBackTransaction();
}
catch (IOException e)
{
//Again we need the rollback
rollBackTransaction();
}

For the first part it makes no big difference - a little less work
with using exceptions.
In the second part you can't easily see (without examing javadoc of
the called methods) which lines could have produced the exception.
Encapsulating every single operation with try-catch is clearly not an
option as it produces much more boilerplate (if several lines could
throw the same exceptions) than using return codes. An advantage of
using return codes is having a clear information about the overall
status of the whole operation "automatically".

BUT: I think the handling of the different exceptions can be solved
with throwing your own Exception type instead of returning a
resultCode. And I think to remember something like this recommended by
Josh Bloch in his book "Effective Java" (just don't remember which
item and I don't have the book at hand). The only thing is the need of
an extra Class for your application exception(s). Hey, and you can
throw an exception that contains either a return code - there you
would have everything. - Remaining issue is only that in some cases I
simply don't care of the return codes and I can decide this in the
parent method. But this can be solved using Unchecked Exceptions
instead of checked exceptions. - And this is the point where I love to
have the option of using checked or unchecked exceptions.

Thank you guys - with your help I got cleared that up.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

As I said: in cases where you want to have a version of your code where 
the exception bubbles up and one where it doesn't you'll get the 
duplication. I think that is usually a bad idea, although I must admit 
the wrapper case you describe is an exception since the layer is the 
same. I don't see that problem spread too far, though.

If your code is really that big, I'd even consider this:

public class UnsafeWrapper implements UnsafeInterface {
protected UnsafeInterface orig;
...
public doAction() throws Ex {
 ...
 orig.doAction();
 
}
}

public class SafeWrapper implements SafeInterface {
...
public doAction() {
   ...
   try {
   orig.doAction(); // call on UnsafeWrapper.doAction()
   } catch(Ex e) {
   // won't happen
   }
}
}

Not very elegant, but avoids major duplication.

I believe that with union types the whole problem would disappear since 
the subtyping would allow using generics to create the different 
versions. As long as exceptions are not part of the type signature it 
won't happen in Java.

   Peter


Reinier Zwitserloot wrote:
> Peter, I still don't see how that'll avoid code duplication.
>
> Let's say, for argument's sake, that a FilterInputStream's read()
> method contains 4 pages of complex code. This code calls back into the
> filtered stream's read method loads of times. How would we avoid
> duplicating these 4 pages if we want 2 types of FilterInputStream: One
> that wraps a Safe InputStream and does not throw IOException, and one
> that wraps an unsafe InputStream and does throw IOException.
>
> On Aug 20, 9:36 am, Peter Becker  wrote:
>   
>> Here you go (three files):
>>
>> = test/Unsafe.java==
>> package test;
>>
>> import java.io.IOException;
>>
>> public interface Unsafe {
>> void method() throws IOException;
>>
>> }
>>
>> = test/Safe.java ==
>> package test;
>>
>> public interface Safe extends Unsafe {
>> void method();
>>
>> }
>>
>> =test/Test.java===
>> package test;
>>
>> import java.io.IOException;
>>
>> public class Test {
>> class UnsafeImpl implements Unsafe {
>> @Override
>> public void method() throws IOException {
>> throw new IOException(); // ok
>> }
>> };
>>
>> class SafeImpl implements Safe {
>> @Override
>> public void method() {
>> // can't throw here
>> }
>> };
>>
>> void method1(Unsafe unsafe) {
>> unsafe.method(); // error, need to deal with exception
>> }
>>
>> void method2(Safe safe) {
>> safe.method(); // ok
>> }
>>
>> }
>>
>> ==
>>
>> The one trick is to realize that the safe version is actually the more
>> specific one. If you think of the exception in terms of the type union
>> (not accurate, but a decent analogy), then Unsafe.method() returns
>> void|IOException while Safe.method() returns void, which is a more
>> specific type, thus the return types are co-variant.
>>
>> More generally you can argue that Safe.method() makes stronger
>> guarantees about its behavior than Unsafe.method(), so subtyping is
>> legal. Apart from the one marked position the code above is legal Java.
>>
>>   Peter
>>
>>
>>
>> Reinier Zwitserloot wrote:
>> 
>>> On Aug 20, 12:21 am, Peter Becker  wrote:
>>>   
 No implementation would be duplicated, the safe version could be a
 subtype of the unsafe one. Not too many interfaces will face that
 problem. To me it seems much better than not distinguishing.
 
>>> Can you show me how this would work?
>>>   
>>> I have a hard time seeing how you can do that without (oh, the irony),
>>> employing some sort of sneakythrow mechanism.
>>>   
>>> I guess we will have to agree to disagree here, but I'm fairly sure
>>> the idealism lost in allowing sneakythrow is minor, whereas the amount
>>> of pain you can solve is sizable. (in practice, due to widespread bad
>>> API design we all know will never ever get fixed, such as in the core
>>> JDK)
>>>   
> >
>   


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

I still kind-of like listening to Joel and Jeff. Both make me cringe at 
times, but I like their attitude towards product design and I think Joel 
has quite some insight into the marketing/business side of software.

But I don't think I'd want either as the chief architect of some 
enterprise software :-)

  Peter


Casper Bang wrote:
> I lost my respect for Joel a while ago -  he comes at you in very
> bold, definitive and authoritative fashion (especially on
> StackOverflow where he's down right annoying). Exceptions cater well
> to OO, you can centralize error handling and dispatching via
> polymorphism as well as associate whatever context that's needed. I
> don't think (hope) many in here wants to go back to interpreting
> return values.
>
> /Casper
>
> On 20 Aug., 16:03, Martin Wildam  wrote:
>   
>> Anyone a fan of this:http://www.joelonsoftware.com/items/2003/10/13.html
>>
>> I am. :-)
>> 
> >
>   


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Number one clearly does not apply to checked exceptions, number two 
applies to returning values, too. Of course you could assign a value and 
follow the approach of having a single return statement at the end, but 
I never understood why the resulting code should be any easier.

  Peter


Martin Wildam wrote:
> Anyone a fan of this: http://www.joelonsoftware.com/items/2003/10/13.html
>
> I am. :-)
> >
>   


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Christian Catchpole]

Yep.  That's my approach.

> Guys If you don't know how to handle exception for a given method then
> you are better off simply throwing it.

This sentence may confuse some who will assume they have to catch it
in the first place.  Maybe a better phrase is:
"If you don't know how to handle exception for a given method then
just don't catch it."

Hey, I just had an idea.  Why not compile this with Reinier's
checkless compiler, jar it up and include it in your normal projects..

public class Throw {
public static void unchecked(Throwable throwable) {
throw throwable;
}
}

all you need to do, where you would normally wrap the exception in a
runtime exception is do this..

public void method() {
try {
...
} catch (SQLException sqle) {
   Throw.unchecked(sqle);
}
}

On Aug 21, 6:30 pm, "a.efremov"  wrote:
> Hello,
>
> Let me to say what I think on that topic.
> Guys If you don't know how to handle exception for a given method then
> you are better off simply throwing it. Just add it to the method
> declaration. That's all about that.
> Handle only exceptions in case you are know for sure how to deal with
> a failure/error.
>
> In some cases you can simply wrap an exception into RuntimeException.
> It sounds like you convert it to an error intentionally. kinda
> exception handling. It makes sense for wealth of situations.
>
> Don't write useless boilerplate code that in many cases is cause of an
> error. Keep the things as simple as there are.
>
> alexander
>
> On Aug 18, 4:55 am, Christian Catchpole 
> wrote:
>
>
>
> > No, i just let that go up.  I really try to avoid the declare as null
> > then set thingy.
>
> > On Aug 18, 12:03 pm, Casper Bang  wrote:
>
> > > You neglect to handle the checked exception declared by
> > > prepareStatement no?
>
> > > PreparedStatement stmt = null;
> > > try{
> > >     stmt = connection.prepareStatement(sql);
> > >     final ResultSet rs = stmt.executeQuery();
> > >     try{
> > >         while (rs.next()){
> > >             // Stuff...
> > >         {
> > >     }
> > >     finally{
> > >         rs.close();
> > >     }}
>
> > > catch(SQLException e){
> > >     // Logging...}
>
> > > finally{
> > >     try{
> > >         stmt.close();
> > >     }
> > >     catch(SQLException whoTheFuckCares){
> > >     };
>
> > > }
>
> > > Really, how many other ways are there to do it I wonder now? (Apart
> > > from wrapping certain things, like the last try-catch clause in some
> > > general purpose "closer util"?).
>
> > > /Casper
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

> If you don't know how to handle exception for a given method then
> you are better off simply throwing it. Just add it to the method
> declaration. That's all about that.

I agree with you - however, I have many common functions that are used
under several different circumstances where in some cases an error
could simply be ignored and in others not.

Example: I have common methods for reading configuration files. In
some cases it is completely irrelevant if they do not exist because
they are only optional - or it would be good to log a warning if the
file does not exist. In other cases it is critical if the file can't
be found. Passing the exception to the caller means that I am creating
boilerplate code for 50 % of the cases. Using a return value does not.

But: Reading the arguments of you and others here I got convinced that
using exceptions is a good practice. I solution I am thinking of is to
write different methods for different usages - one for loading needed
config files and one for loading optionals - talking about the sample
given above (but I have plenty of similar functions with "conflicting
use cases").
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[a.efremov]

Hello,

Let me to say what I think on that topic.
Guys If you don't know how to handle exception for a given method then
you are better off simply throwing it. Just add it to the method
declaration. That's all about that.
Handle only exceptions in case you are know for sure how to deal with
a failure/error.

In some cases you can simply wrap an exception into RuntimeException.
It sounds like you convert it to an error intentionally. kinda
exception handling. It makes sense for wealth of situations.

Don't write useless boilerplate code that in many cases is cause of an
error. Keep the things as simple as there are.

alexander

On Aug 18, 4:55 am, Christian Catchpole 
wrote:
> No, i just let that go up.  I really try to avoid the declare as null
> then set thingy.
>
> On Aug 18, 12:03 pm, Casper Bang  wrote:
>
> > You neglect to handle the checked exception declared by
> > prepareStatement no?
>
> > PreparedStatement stmt = null;
> > try{
> >     stmt = connection.prepareStatement(sql);
> >     final ResultSet rs = stmt.executeQuery();
> >     try{
> >         while (rs.next()){
> >             // Stuff...
> >         {
> >     }
> >     finally{
> >         rs.close();
> >     }}
>
> > catch(SQLException e){
> >     // Logging...}
>
> > finally{
> >     try{
> >         stmt.close();
> >     }
> >     catch(SQLException whoTheFuckCares){
> >     };
>
> > }
>
> > Really, how many other ways are there to do it I wonder now? (Apart
> > from wrapping certain things, like the last try-catch clause in some
> > general purpose "closer util"?).
>
> > /Casper
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

This thread inspired me. Thanks in particular to Casper. Here you go,
an annotation processor that removes the notion of checked exceptions
completely from your javac:

http://groups.google.com/group/javaposse/browse_thread/thread/26ec00e0601023d

On Aug 21, 12:00 am, phil swenson  wrote:
> well put :)
>
> On Aug 20, 8:36 am, Reinier Zwitserloot  wrote:
>
>
>
> > Joel on Software's view that exceptions are bad and you should be
> > using archaic C style error codes is, in a word: Effing Retarded.
>
> > Follow his advice at your own peril.
>
> > On Aug 20, 4:03 pm, Martin Wildam  wrote:
>
> > > Anyone a fan of this:http://www.joelonsoftware.com/items/2003/10/13.html
>
> > > I am. :-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[phil swenson]

well put :)

On Aug 20, 8:36 am, Reinier Zwitserloot  wrote:
> Joel on Software's view that exceptions are bad and you should be
> using archaic C style error codes is, in a word: Effing Retarded.
>
> Follow his advice at your own peril.
>
> On Aug 20, 4:03 pm, Martin Wildam  wrote:
>
> > Anyone a fan of this:http://www.joelonsoftware.com/items/2003/10/13.html
>
> > I am. :-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[James Iry]

Exactly.  The Camera/Gun argument against structural typing doesn't hold
water because the programmer's error is exactly the same semantic problem as


// my library
interface Camera {
   void shoot();
}

// somebody else's code
class Bazooka extends Camera {...}

The only constraints that Java can enforce on implementing the Camera
interface are structural, it knows nothing about our domain.  In this
particular case the mistake seems silly because of our intuition that
Bazookas aren't Cameras.  But Java also allows us to say

// my library
// this interface is for things that "shoot" non-destructively like still
cameras, video cameras, and sextants.
interface Shootable {
  void shoot();
}

Now writing "class Bazooka extends Shootable {...}" violates the library's
constraint, but the constraint is in documentation that is easily missed by
a programmer.  In this toy domain that seems contrived, but real world
examples abound where classes implement the structural requirements of an
interface but don't follow the additional requirements in the documentation.

On Thu, Aug 20, 2009 at 2:26 AM, Ben Schulz  wrote:

>
> > should that be legal code? I'd argue no - the fact that both Gun and
> > Camera have a 'shoot' method is a pure coincidence.
>
> I don't think that argument works here. Yeah, idiots will be idiots,
> but it would take an extraordinary idiot to call shoot() on an object
> of type "Gun|Camera". Why do you insist on having more slack in your
> type system, just to exclude a tiny class of errors that noone is
> going to make anyways?
>
> With kind regards
> Ben
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[James Iry]

On Wed, Aug 19, 2009 at 11:45 AM, Reinier Zwitserloot wrote:

>
> disjoint types are structural in that you weaken the namespacing of
> members.
>
>
Disjoint types aren't structural unless the language makes them so.  Java
could be extended with disjoint types that compute a least upper bound
nominally rather than structurally.  Or it could require type dispatch and
never use a LUB.  As for namespacing, well it can't be made any weaker than
it already is.  It's a weak concept and always has been.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[James Iry]

C style error codes suck because they're too easy to forget to check (by the
way, null is a lot like a C style error code because it extends the normal
domain of a result invisibly, so it sucks too).

But to be fair Joel also talked about the ML/Haskell(/Scala/F#/etc) style of
returning an algebraic data type that indicates a "good result" in a certain
domain vs a "bad result," so forgetting to check isn't such a problem and
the use of higher order functions and/or monad comprehensions takes the
sting out of checking.  So in those languages you have viable alternatives
to exceptions without the nastiest downsides of C style error codes.

If/when Java gets lambdas, that style of coding will become viable in it as
well.

That said, even in those languages you'll find exceptions used much more
than Joel might like.  Algebraic types like "Maybe/Option" and "Either,"
even though relatively pleasant to use, aren't invisible and often
"invisible" really is a better way to go.


On Thu, Aug 20, 2009 at 7:36 AM, Reinier Zwitserloot wrote:

>
> Joel on Software's view that exceptions are bad and you should be
> using archaic C style error codes is, in a word: Effing Retarded.
>
> Follow his advice at your own peril.
>
> On Aug 20, 4:03 pm, Martin Wildam  wrote:
> > Anyone a fan of this:http://www.joelonsoftware.com/items/2003/10/13.html
> >
> > I am. :-)
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

It's a borderline case, so removing the ability to call shoot() on a
Gun|Camera isn't that important, but I would argue that allowing it
means you're in structural typing land. I'd actually say that Allowing
shoot() on a Gun|Camera is more slack in the type system vs. not
allowing it.


On Aug 20, 11:26 am, Ben Schulz  wrote:
> On 19 Aug., 20:45, Reinier Zwitserloot  wrote:
>
>
>
>
>
> > disjoint types are structural in that you weaken the namespacing of
> > members.
>
> > Members are only namespaced by virtue of their container. So lets say
> > I do this (I apologize in advance for the cliché factor of this
> > example):
>
> > public class com.ren.Gun {
> >     public void shoot() { System.out.println("BANG!"); }
>
> > }
>
> > public class com.stimpy.Camera {
> >     public void shoot() { System.out.println("Smile!"); }
>
> > }
>
> > public void pointAndClick(Gun | Camera object) {
> >     object.shoot();
>
> > }
>
> > should that be legal code? I'd argue no - the fact that both Gun and
> > Camera have a 'shoot' method is a pure coincidence.
>
> I don't think that argument works here. Yeah, idiots will be idiots,
> but it would take an extraordinary idiot to call shoot() on an object
> of type "Gun|Camera". Why do you insist on having more slack in your
> type system, just to exclude a tiny class of errors that noone is
> going to make anyways?
>
> With kind regards
> Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

Peter, I still don't see how that'll avoid code duplication.

Let's say, for argument's sake, that a FilterInputStream's read()
method contains 4 pages of complex code. This code calls back into the
filtered stream's read method loads of times. How would we avoid
duplicating these 4 pages if we want 2 types of FilterInputStream: One
that wraps a Safe InputStream and does not throw IOException, and one
that wraps an unsafe InputStream and does throw IOException.

On Aug 20, 9:36 am, Peter Becker  wrote:
> Here you go (three files):
>
> = test/Unsafe.java==
> package test;
>
> import java.io.IOException;
>
> public interface Unsafe {
>     void method() throws IOException;
>
> }
>
> = test/Safe.java ==
> package test;
>
> public interface Safe extends Unsafe {
>     void method();
>
> }
>
> =test/Test.java===
> package test;
>
> import java.io.IOException;
>
> public class Test {
>     class UnsafeImpl implements Unsafe {
>         @Override
>         public void method() throws IOException {
>             throw new IOException(); // ok
>         }
>     };
>
>     class SafeImpl implements Safe {
>         @Override
>         public void method() {
>             // can't throw here
>         }
>     };
>
>     void method1(Unsafe unsafe) {
>         unsafe.method(); // error, need to deal with exception
>     }
>
>     void method2(Safe safe) {
>         safe.method(); // ok
>     }
>
> }
>
> ==
>
> The one trick is to realize that the safe version is actually the more
> specific one. If you think of the exception in terms of the type union
> (not accurate, but a decent analogy), then Unsafe.method() returns
> void|IOException while Safe.method() returns void, which is a more
> specific type, thus the return types are co-variant.
>
> More generally you can argue that Safe.method() makes stronger
> guarantees about its behavior than Unsafe.method(), so subtyping is
> legal. Apart from the one marked position the code above is legal Java.
>
>   Peter
>
>
>
> Reinier Zwitserloot wrote:
> > On Aug 20, 12:21 am, Peter Becker  wrote:
>
> >> No implementation would be duplicated, the safe version could be a
> >> subtype of the unsafe one. Not too many interfaces will face that
> >> problem. To me it seems much better than not distinguishing.
>
> > Can you show me how this would work?
>
> > I have a hard time seeing how you can do that without (oh, the irony),
> > employing some sort of sneakythrow mechanism.
>
> > I guess we will have to agree to disagree here, but I'm fairly sure
> > the idealism lost in allowing sneakythrow is minor, whereas the amount
> > of pain you can solve is sizable. (in practice, due to widespread bad
> > API design we all know will never ever get fixed, such as in the core
> > JDK)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

On Aug 20, 4:13 pm, Casper Bang  wrote:
> Exceptions cater well to OO, you can centralize error handling and 
> dispatching via
> polymorphism as well as associate whatever context that's needed. I
> don't think (hope) many in here wants to go back to interpreting
> return values.

I don't know Joel personally but when dealing with exceptions for a
while I found by accident his opinion on Exceptions and I felt so
happy not being the only one not using exceptions all the time. - I
personally also use exceptions but for some very common methods that
are definitely useful in definitely very different cases it really
makes sense coming back to return values. - At least not only from my
point of view.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

I lost my respect for Joel a while ago -  he comes at you in very
bold, definitive and authoritative fashion (especially on
StackOverflow where he's down right annoying). Exceptions cater well
to OO, you can centralize error handling and dispatching via
polymorphism as well as associate whatever context that's needed. I
don't think (hope) many in here wants to go back to interpreting
return values.

/Casper

On 20 Aug., 16:03, Martin Wildam  wrote:
> Anyone a fan of this:http://www.joelonsoftware.com/items/2003/10/13.html
>
> I am. :-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Martin Wildam]

Anyone a fan of this: http://www.joelonsoftware.com/items/2003/10/13.html

I am. :-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

Joel on Software's view that exceptions are bad and you should be
using archaic C style error codes is, in a word: Effing Retarded.

Follow his advice at your own peril.

On Aug 20, 4:03 pm, Martin Wildam  wrote:
> Anyone a fan of this:http://www.joelonsoftware.com/items/2003/10/13.html
>
> I am. :-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Ben Schulz wrote:
>> The one trick is to realize that the safe version is actually the more
>> specific one. If you think of the exception in terms of the type union
>> (not accurate, but a decent analogy), then Unsafe.method() returns
>> void|IOException while Safe.method() returns void, which is a more
>> specific type, thus the return types are co-variant.
>> 
>
> I think Reinier was refering to this:
>
> x.doSomething(new StringReader("xyz"));
> x.doSomething(someUnsafeReader());
>
> Unless you have two overloads of doSomething both invocations will
> throw an IOException. Having two overloads is code duplication though.
> Even if it looks like that:
>
> public void doSomething(SafeReader r) {
> try {
> doSomething((UnsafeReader)r);
> } catch(IOException e) {
> throw new RuntimeException(e);
> }
> }
>   
Here's my version of the story:

If you are happy to deal with the exception, then just write the version 
for the UnsafeReader which will take SafeReader implementations.

If you don't want to allow the exceptions, write the SafeReader version 
only.

If you feel the need to pass the exceptions through without dealing with 
them (not even wrapping them into an exception suitable for your layer), 
then you are probably creating a leaky abstraction.

But I agree that this pattern could not easily be retrofitted into the 
JDK or other code.

  Peter

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Ben Schulz]

On 19 Aug., 20:45, Reinier Zwitserloot  wrote:
> disjoint types are structural in that you weaken the namespacing of
> members.
>
> Members are only namespaced by virtue of their container. So lets say
> I do this (I apologize in advance for the cliché factor of this
> example):
>
> public class com.ren.Gun {
>     public void shoot() { System.out.println("BANG!"); }
>
> }
>
> public class com.stimpy.Camera {
>     public void shoot() { System.out.println("Smile!"); }
>
> }
>
> public void pointAndClick(Gun | Camera object) {
>     object.shoot();
>
> }
>
> should that be legal code? I'd argue no - the fact that both Gun and
> Camera have a 'shoot' method is a pure coincidence.

I don't think that argument works here. Yeah, idiots will be idiots,
but it would take an extraordinary idiot to call shoot() on an object
of type "Gun|Camera". Why do you insist on having more slack in your
type system, just to exclude a tiny class of errors that noone is
going to make anyways?

With kind regards
Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Ben Schulz]

> The one trick is to realize that the safe version is actually the more
> specific one. If you think of the exception in terms of the type union
> (not accurate, but a decent analogy), then Unsafe.method() returns
> void|IOException while Safe.method() returns void, which is a more
> specific type, thus the return types are co-variant.

I think Reinier was refering to this:

x.doSomething(new StringReader("xyz"));
x.doSomething(someUnsafeReader());

Unless you have two overloads of doSomething both invocations will
throw an IOException. Having two overloads is code duplication though.
Even if it looks like that:

public void doSomething(SafeReader r) {
try {
doSomething((UnsafeReader)r);
} catch(IOException e) {
throw new RuntimeException(e);
}
}

With kind regards
Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Ben Schulz]

On 20 Aug., 05:51, Casper Bang  wrote:
> Why don't we just change checked exception from being an error to
> being a warning? It would not break any kind of compatibility. And as
> a library author, you still get the power to tell your clients that
> here's something to pay special attention to, but without getting in
> the way of people doing fast and ad-hoc prototyping/refactoring/
> debugging.

Excellent idea, but you could get the same results in a language with
annotations and an annotation processor without wiring it into the
language.

With kind regards
Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Here you go (three files):

= test/Unsafe.java==
package test;

import java.io.IOException;

public interface Unsafe {
void method() throws IOException;
}

= test/Safe.java ==
package test;

public interface Safe extends Unsafe {
void method();
}

=test/Test.java===
package test;

import java.io.IOException;

public class Test {
class UnsafeImpl implements Unsafe {
@Override
public void method() throws IOException {
throw new IOException(); // ok
}
};

class SafeImpl implements Safe {
@Override
public void method() {
// can't throw here
}
};

void method1(Unsafe unsafe) {
unsafe.method(); // error, need to deal with exception
}

void method2(Safe safe) {
safe.method(); // ok
}
}

==

The one trick is to realize that the safe version is actually the more 
specific one. If you think of the exception in terms of the type union 
(not accurate, but a decent analogy), then Unsafe.method() returns 
void|IOException while Safe.method() returns void, which is a more 
specific type, thus the return types are co-variant.

More generally you can argue that Safe.method() makes stronger 
guarantees about its behavior than Unsafe.method(), so subtyping is 
legal. Apart from the one marked position the code above is legal Java.

  Peter


Reinier Zwitserloot wrote:
> On Aug 20, 12:21 am, Peter Becker  wrote:
>   
>> No implementation would be duplicated, the safe version could be a
>> subtype of the unsafe one. Not too many interfaces will face that
>> problem. To me it seems much better than not distinguishing.
>> 
>
> Can you show me how this would work?
>
> I have a hard time seeing how you can do that without (oh, the irony),
> employing some sort of sneakythrow mechanism.
>
> I guess we will have to agree to disagree here, but I'm fairly sure
> the idealism lost in allowing sneakythrow is minor, whereas the amount
> of pain you can solve is sizable. (in practice, due to widespread bad
> API design we all know will never ever get fixed, such as in the core
> JDK)
>
> >
>   



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

I actually don't mind that idea. My code tends to be warning free and I 
shy away from the @SuppressWarning, so for me not much would change.

And I guess people at the other end of the spectrum ignore/suppress 
other warnings already, so it might fit with existing patterns for them.

  Peter


Casper Bang wrote:
> Why don't we just change checked exception from being an error to
> being a warning? It would not break any kind of compatibility. And as
> a library author, you still get the power to tell your clients that
> here's something to pay special attention to, but without getting in
> the way of people doing fast and ad-hoc prototyping/refactoring/
> debugging.
>
> If this was the default behavior of checked exceptions, I would
> probably be for them. One could even introduce SuppressWarnings
> ("checked") as a cleaner version of Lombok's @SneakyThrows. I have a
> javac where this has been done (along with converting
> UnreachableStatement to a warning and allow checked exception catch
> without a throw) and it appears to work nicely.
>
> /Casper
> >
>   



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

On Aug 20, 12:21 am, Peter Becker  wrote:
> No implementation would be duplicated, the safe version could be a
> subtype of the unsafe one. Not too many interfaces will face that
> problem. To me it seems much better than not distinguishing.

Can you show me how this would work?

I have a hard time seeing how you can do that without (oh, the irony),
employing some sort of sneakythrow mechanism.

I guess we will have to agree to disagree here, but I'm fairly sure
the idealism lost in allowing sneakythrow is minor, whereas the amount
of pain you can solve is sizable. (in practice, due to widespread bad
API design we all know will never ever get fixed, such as in the core
JDK)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

Why don't we just change checked exception from being an error to
being a warning? It would not break any kind of compatibility. And as
a library author, you still get the power to tell your clients that
here's something to pay special attention to, but without getting in
the way of people doing fast and ad-hoc prototyping/refactoring/
debugging.

If this was the default behavior of checked exceptions, I would
probably be for them. One could even introduce SuppressWarnings
("checked") as a cleaner version of Lombok's @SneakyThrows. I have a
javac where this has been done (along with converting
UnreachableStatement to a warning and allow checked exception catch
without a throw) and it appears to work nicely.

/Casper
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

That would be structural, but I wouldn't allow it. The union type in a 
manifest typed system should allow only calls to methods declared on 
common supertypes of all types in the union. In your example that seems 
to be Object.

To pick Reinier's example: if you get something that's either a gun or a 
camera, then you'll have to figure out which one it is first.

In most cases I would expect an anonymous union to be used in a switch 
statement or similar construct. You could have cases where one of the 
common supertypes is sufficient, things like Number or Exception come to 
mind. But in the bigger picture I'd expect that to be a less common case.

  Peter


Ben Schulz wrote:
> That's what I was refering to as having to check the runtime type. I
> don't feel like you gained much in your sample, you could just replace
> "String | Integer" with Object and add a "default: throw new
> AssertionError();". Obviously you gained type safety, but it would be
> much more useful if unions were structural:
>
> public static void closeSilently(InputStream|OutputStream|Reader|
> Writer|Channel preCloseable) {
> try {
> preCloseable.close();
> } catch(IOException e) {}
> }
>
> With kind regards
> Ben
>
> On 19 Aug., 15:57, James Iry  wrote:
>   
>> I don't follow.  Union types don't seem particularly structural to me.
>> They're the disjunction of other types, and if the other types are
>> nominative then so is the union of them.  A type like String | Integer
>> contians all expressions that are Strings or Integers. The idea would be
>> that you can write the followig.  Here I'm borrowing a touch of Scala syntax
>> to allow switch on runtime type and use | to indicate disjunction of types.
>>
>> void foo(String | Integer argument) {
>>  switch(argument) {
>>case s : String => "It was a String " + s
>>break;
>>case i : Integer => "It was an Integer " + i
>>  }
>>
>> }
>>
>> The types of actual arguments would be checked statically.  The type system
>> would allow foo("hello") and foo(42) but would not allow foo(false).  For
>> backward compatibility, the argumenttype could be erased to the least upper
>> bound (in this case Object) in the bytecode.
>>
>> Similarly, you could write
>>
>> String | Integer foo(Boolean flag) {
>>if (flag) return 42;
>>else return "hello";
>>
>> }
>> On Wed, Aug 19, 2009 at 4:21 AM, Ben Schulz  wrote:
>>
>> 
>>> I'm not much of a PLTist, but I'm guessing the reason uions don't make
>>> it into general purpose, object oriented languages is that they're
>>> inherently structural. Just a guess though. (The alternative is having
>>> to check the runtime type and downcast, which pretty much defeats the
>>> purpose.)
>>>   
>>> With kind regards
>>> Ben
>>>   
> >
>   



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Ben Schulz wrote:
>> Obviously you gained type safety,
>>
>> Isn't that kinda the point of a type system?  :-)
>> 
>
> I suppose, but for me it's more about why I should write down the
> types. If we asked Gilad Bracha, he'd probably say it's a bad idea
> because they restrain your thinking. Me, I say it's good because the
> compiler can verify that all messages sent are understood by their
> receivers. Structural unions would get me much farther in that
> direction and that's where I want to go. If I understand it correctly
> (and I can only hope in this case) I would not need to write down any
> types if higher-order unification was decidable. Wouldn't that be
> nice?
>   
I'm all for manifest typing: 
http://blog.peterbecker.de/2008/05/i-manifest-typing.html

But I find that the notions of "anything that is X and Y" and "anything 
that is X or Y" are natural concepts in such a system, which should be 
easily expressible. I tend to think of it in terms of Formal Concept 
Analysis[1], where these would be the join and meet operations in the 
complete lattice you get if you allow them. One nice thing is that they 
give you the missing type in this:

interface X extends A,B {...}
interface Y extends A,B {...}

In Java the supertype of X and Y is not clear. It is X|Y, which in a 
closed world would be the same as A&B. [for the reference: this is 
called the Dedekind-McNeill completion]

While this all might sound very academic, I find it very intuitive and 
tend to see the same in less mathematically inclined people. Saying 
"either X or Y" and "both A and B" is quite natural and the fact that 
you can not express either statement in the current type systems is a 
limitation IMO. Since a complete lattice is computationally not too bad, 
I really wonder why no one addressed this issue yet. The cynic in me 
thinks it is just because programmers love thinking in trees.

  Peter


[1] http://en.wikipedia.org/wiki/Formal_concept_analysis



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Reinier Zwitserloot wrote:
> Replies inline. The problem is simply this: You think I was trying to
> argue against checked exceptions in general. I wasn't. I was arguing
> that the checked exception system isn't perfect, and therefore
> programmers need to be given a tool to say to the compiler: I know
> better than you. Stop whining.
>
> More specific arguments follow below, inline.
>
> On Aug 19, 12:56 am, Peter Becker  wrote:
>   
>>> Runnable does not let you throw Exceptions. Anyone up for defending
>>> this grievous API design? The amount of annoyance that this is caused
>>> me is almost limitless.
>>>   
>> Where would that exception go?
>> 
>
> The same place the RuntimeExceptions thrown by the runnable go. Your
> argument only makes sense if Runnable was precluded from throwing -any
> and all- exceptions. That's not true. What possible use is there for
> someone invoking a Runnable (which after all stands for: I have no
> idea what this does, other than run... something...) - to
> differentiate between checked exceptions and unchecked exceptions? The
> thing threw an exception. It doesn't matter what kind of exception was
> thrown.
>
> So, for Thread, that would be: The exception handler of that thread.
>   
Fair enough. I keep forgetting about runtime exceptions, that's why I 
like the checked ones :-)

[...]
>> If you just allow any exception to go through (e.g. by letting the
>> methods throw Exception on the API level), programmers will forget to
>> handle things they could handle.
>> 
>
> Idiots write idiot code. But, okay, I'll roll with your argument: Then
> why isn't there a mechanism to escape it? Why can't I say: Nono,
> compiler, I did not forget anything, this is what I want. Shut your
> yap. You're not really going to argue with me that there is no
> inconvenience at all here, right?
>   
The problem I see is that someone on a lower layer might have done this 
and the guy on the layer above is not aware of it. I know you will 
counter with the argument that the alternative is bad catches, and I 
agree to some extent. But those catches you describe (the 
e.printStackTrace() and similar) are known to be bad, adding a mechanism 
to the language makes it look much more legit. Of course the new 
RuntimeException(e) is much better, but I don't think it is a general 
solution either.
>
>   
>>> InputStream.close() throws IOException. Nuff said.
>>>   
>> That only proves that exceptions are used badly in the JDK.
>> 
>
> That "only" proves? The JDK abuses checked exceptions - That's a
> pretty big deal! That's the whole point! That's why the language needs
> an escaping mechanism.
>   
It doesn't seem right to add language features to deal with crappy 
library design.
> The further damage caused by bad coders abusing the escaping mechanism
> are, in my opinion, much, __much__ smaller than the potential further
> damage that would no longer becaused because the mechanism is
> available. The occasional explicitly supressed checked exception that
> should have been handled is far less of a crime than code littered
> with this abomination:
>
> try {
> something();
> } catch ( IOException e ) {
>e.printStackTrace();
>//TODO Eclipse auto-generated this. The programmer never looked at
> it again, logging to system.err is just about the worst thing you
> could do here, and the original programmer only hit quickfix-add try
> catch block because he couldn't throw it onwards because he's
> implementing a servlet, or a runnable.
> }
>
> Sure, an idiot coded that. But we're all idiots some of the time, and
> you yourself put 'idiots exist' on the table as a legal line of
> reasoning.
>   
What you are proposing seems to me like making a mediocre solution easy 
to avoid people doing the really bad ones.  Call me an idealist, but I 
don't really like that.

Just think of the problem one layer above the one that may use the 
sneaky throws: you might get some methods you call that pass the 
IOException to you, some might do what I consider right and chain it 
with their own checked exception and other just do the sneaky throw. To 
figure out what's happening I really need to know the internals of each 
method down to the bottom. The alternative is catch(Exception).

Admittedly the problem is already there since Java has both checked and 
unchecked exceptions.

>>> FilterInputStream and FilterOutputStream's methods throw IOException,
>>> but if I feed it a ByteArrayInputStream, or I let it filter into a
>>> ByteArrayOutputStream, then an IOException can never happen.
>>>   
>> Which could be solved by having safe and unsafe versions of the interface.
>>
>> 
>
> Do you realize how much code duplication that would require? Exactly
> _BECAUSE_ you can't circumvent checked exception checking, you'd
> actually have to copy/paste every method. I cannot put into words the
> insanity of a system that would _require_ you to copy/paste vast
> tracts of code just to satisfy a sys

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

phil swenson wrote:
>
> On Aug 18, 4:48 pm, Peter Becker  wrote:
>   
>> phil swenson wrote:
>> So you are saying it is better to quietly change behaviour than to make
>> a change to an API that breaks source compatibility? I certainly would
>> not agree to that.
>> 
>
> So every API written in every other language ever written in the
> history of software got it wrong eh?
>   
How do you infer that? In fact you get the other extremes like the MS 
APIs where no method every gets changed, they just add "Ex" or numbers 
at the end for the new versions. Not pretty either, but it is one way to 
deal with the problem.
> Exceptions mean something went wrong.  You will detect this when it
> happens (testing, iterative dev).  And again, it's almost always
> because of a bug or something else you can't gracefully handle (like
> server down as you mention).  If you decide to handle one of these
> conditions, that's fine - but usually it's better to let the condition
> bubble up to the top thread an notify the user/email the admin.
>
>
>   
>> Sorry, but I call BS on that. SQLExceptions get thrown when the DB
>> server is down or in trouble, when the network has issues and possibly
>> other reasons that you do not encounter in test environments, so your
>> testing won't help.
>> 
>
> Ok, I modify my original claim of "it's almost always a bug" to "it's
> almost always a bug or a condition that you can't do anything about in
> code".  If your db server is down, all you can do it manually
> intervene and get the thing running again.  If you are in a scenario
> where data loss is unacceptable (where you would do a catch/retry),
> then you still need to handle runtime exceptions anyway.
>   
Where I might say that runtime exceptions are the evil ;-)
> The key is to make the exception known and notify someone.  Checked
> exceptions usually have the opposite effect.  You can say "that's
> because people don't use them correctly."  Sure, but I still haven't
> seen anyone who does use them correctly.  It's too much of a PITA.
>   
And my argument is that it is such a PITA (to which I agree) at least 
partly because the lowest layers (the JDK) did it wrong.

I just realize I might not ever have described what I consider a nice 
design for checked exceptions. Let me try this.

The general assumption is that your code is nicely modularized. Each 
module should then have a few (normally just one) base exception, saying 
something like "an operation in this module failed". SQLException could 
be in theory such a thing.

Then you subtype this exception for every error condition. That allows 
the user to either generally catch errors in your module (by catching 
the base type) or be more specific to handle certain error cases more 
gracefully. Ideally your base exception is never instantiated directly, 
although you might want to allow it in a throws clause.

For each method you try to reduce the allowed exceptions. There should 
normally be some perfectly safe methods (i.e. no exceptions thrown), 
most other should tend to be quite specific of what can go wrong (i.e. 
throw a few leaf types of your exception hierarchy). If you find that 
the same exceptions are thrown all over your API you might want to think 
about a way to encapsulate the error condition. In cases where IO or 
similar is involved that probably won't help, but in many cases a bit of 
restructuring can localize the potential errors.

If a layer can not handle an exception coming from below, then it should 
most likely be wrapped into a suitable exception along the lines of 
LayerXTechnicalException, ideally enriched by contextual information.

The nice thing about such a design is that by reading the method 
signature it is pretty clear what can go wrong and what can't. With 
decent names not much documentation should be needed, otherwise the 
JavaDoc of the exception class as well as the @throws on the methods are 
great places to put it. If you don't care about the exceptions just 
catch the toplevel exception of the layer and you are fine. If you do 
care, catch specific exceptions and deal with them. If you care only 
about some cases, catch the matching exceptions first and then the 
toplevel one.

  Peter


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

disjoint types are structural in that you weaken the namespacing of
members.

Members are only namespaced by virtue of their container. So lets say
I do this (I apologize in advance for the cliché factor of this
example):

public class com.ren.Gun {
public void shoot() { System.out.println("BANG!"); }
}

public class com.stimpy.Camera {
public void shoot() { System.out.println("Smile!"); }
}

public void pointAndClick(Gun | Camera object) {
object.shoot();
}


should that be legal code? I'd argue no - the fact that both Gun and
Camera have a 'shoot' method is a pure coincidence. They aren't the
same thing at all. Instead, I'd say that such a disjoint type should
only have the members of the common superclass (in this case, that
would be as if 'object' is an Object and no more), with the caveat
that you can pattern match on it. If you indeed cannot call shoot() on
the union of Camera and Gun, it's 100% nominal in my book.

On Aug 19, 6:14 pm, Ben Schulz  wrote:
> > Obviously you gained type safety,
>
> > Isn't that kinda the point of a type system?  :-)
>
> I suppose, but for me it's more about why I should write down the
> types. If we asked Gilad Bracha, he'd probably say it's a bad idea
> because they restrain your thinking. Me, I say it's good because the
> compiler can verify that all messages sent are understood by their
> receivers. Structural unions would get me much farther in that
> direction and that's where I want to go. If I understand it correctly
> (and I can only hope in this case) I would not need to write down any
> types if higher-order unification was decidable. Wouldn't that be
> nice?
>
> With kind regards
> Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Lorenzo]

Hi all,

A few days ago I ran into an interesting article about Java Exceptions
Handling on the Oracle technology website:

http://www.oracle.com/technology/pub/articles/dev2arch/2006/11/effective-exceptions.html

It covers checked/unchecked exceptions and multi-tier hints.

Lorenzo


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[phil swenson]

On Aug 18, 4:48 pm, Peter Becker  wrote:
> phil swenson wrote:
> So you are saying it is better to quietly change behaviour than to make
> a change to an API that breaks source compatibility? I certainly would
> not agree to that.

So every API written in every other language ever written in the
history of software got it wrong eh?
Exceptions mean something went wrong.  You will detect this when it
happens (testing, iterative dev).  And again, it's almost always
because of a bug or something else you can't gracefully handle (like
server down as you mention).  If you decide to handle one of these
conditions, that's fine - but usually it's better to let the condition
bubble up to the top thread an notify the user/email the admin.


> Sorry, but I call BS on that. SQLExceptions get thrown when the DB
> server is down or in trouble, when the network has issues and possibly
> other reasons that you do not encounter in test environments, so your
> testing won't help.

Ok, I modify my original claim of "it's almost always a bug" to "it's
almost always a bug or a condition that you can't do anything about in
code".  If your db server is down, all you can do it manually
intervene and get the thing running again.  If you are in a scenario
where data loss is unacceptable (where you would do a catch/retry),
then you still need to handle runtime exceptions anyway.

The key is to make the exception known and notify someone.  Checked
exceptions usually have the opposite effect.  You can say "that's
because people don't use them correctly."  Sure, but I still haven't
seen anyone who does use them correctly.  It's too much of a PITA.





--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Ben Schulz]

> Obviously you gained type safety,
>
> Isn't that kinda the point of a type system?  :-)

I suppose, but for me it's more about why I should write down the
types. If we asked Gilad Bracha, he'd probably say it's a bad idea
because they restrain your thinking. Me, I say it's good because the
compiler can verify that all messages sent are understood by their
receivers. Structural unions would get me much farther in that
direction and that's where I want to go. If I understand it correctly
(and I can only hope in this case) I would not need to write down any
types if higher-order unification was decidable. Wouldn't that be
nice?

With kind regards
Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Jess Holle]

Thanks for the info.

That would be *great*.

Reinier Zwitserloot wrote:
> I may have mentioned it before, but due to very complex reasons I
> won't go into here, "catching a checked exception that cannot be
> thrown" will most likely become a warning and not an error in java 7.
> So, Jess, your #1 gripe may be about to be resolved*.
>
> *) As there isn't an umbrella JSR, let alone some sort of official
> list of java 7 changes, this isn't set in stone. It is, however, a
> likely requirement in order for a proposal on the coin shortlist
> that's been unanimously well accepted to be backwards compatible. We
> all know how anal sun gets about backwards compatibility, so for once
> you may keep your hopes up.
>
> On Aug 19, 1:58 pm, Jess Holle  wrote:
>   
>> I see this as an important change quite apart from the current debate.
>>
>> Catching an exception that cannot be thrown should be a *warning* not an
>> error.
>>
>> I'm sick of having code stop compiling because someone stopped throwing
>> a checked exception!  That should *not* be a breaking change.  There is
>> justification for a warning -- something changed that you might want to
>> look into and clean up accordingly -- but there's no cause for an error.
>>
>> This would be my #1 gripe about javac -- bar none.
>> //
>>
>>
>>
>> Casper Bang wrote:
>> 
>>> I can confirm this is practice, in fact, the modification to
>>> Check.java I described a few posts ago would also allow compilation of
>>> code with catch clauses of checked exceptions not really being thrown.
>>>   
>>> /Casper
>>>   
> >
>
>   


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[James Iry]

On Wed, Aug 19, 2009 at 7:36 AM, Ben Schulz  wrote:

>
>
> don't feel like you gained much in your sample, you could just replace
> "String | Integer" with Object and add a "default: throw new
> AssertionError();". Obviously you gained type safety,


Isn't that kinda the point of a type system?  :-)   I've pushed the
constraint that "argument" must be either an Integer or a String out of the
documentation where only humans can get at it and into the type system where
both humans and tools can understand it.



> but it would be
> much more useful if unions were structural:
>
> public static void closeSilently(InputStream|OutputStream|Reader|
> Writer|Channel preCloseable) {
>try {
>preCloseable.close();
>} catch(IOException e) {}
> }
>

Agreed, that would be more useful than only having type dispatch.  But union
types can join types that share virtually no common structure, so type
dispatch is a must to make union typing useful while computing  a common
structural type is "merely" very nice for cutting down on code repetition.
In a way you can see this stuff as generalizing what Java already does with
checked exceptions and catch blocks.  Several catch blocks in a series form
a type dispatch mechanism.   It would be nice if unions of exception types
could be caught and dealt with using common code, but the exception system
would be unusable if you couldn't dispatch on individual exception types.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Ben Schulz]

That's what I was refering to as having to check the runtime type. I
don't feel like you gained much in your sample, you could just replace
"String | Integer" with Object and add a "default: throw new
AssertionError();". Obviously you gained type safety, but it would be
much more useful if unions were structural:

public static void closeSilently(InputStream|OutputStream|Reader|
Writer|Channel preCloseable) {
try {
preCloseable.close();
} catch(IOException e) {}
}

With kind regards
Ben

On 19 Aug., 15:57, James Iry  wrote:
> I don't follow.  Union types don't seem particularly structural to me.
> They're the disjunction of other types, and if the other types are
> nominative then so is the union of them.  A type like String | Integer
> contians all expressions that are Strings or Integers. The idea would be
> that you can write the followig.  Here I'm borrowing a touch of Scala syntax
> to allow switch on runtime type and use | to indicate disjunction of types.
>
> void foo(String | Integer argument) {
>  switch(argument) {
>    case s : String => "It was a String " + s
>                break;
>    case i : Integer => "It was an Integer " + i
>  }
>
> }
>
> The types of actual arguments would be checked statically.  The type system
> would allow foo("hello") and foo(42) but would not allow foo(false).  For
> backward compatibility, the argumenttype could be erased to the least upper
> bound (in this case Object) in the bytecode.
>
> Similarly, you could write
>
> String | Integer foo(Boolean flag) {
>    if (flag) return 42;
>    else return "hello";
>
> }
> On Wed, Aug 19, 2009 at 4:21 AM, Ben Schulz  wrote:
>
> > I'm not much of a PLTist, but I'm guessing the reason uions don't make
> > it into general purpose, object oriented languages is that they're
> > inherently structural. Just a guess though. (The alternative is having
> > to check the runtime type and downcast, which pretty much defeats the
> > purpose.)
>
> > With kind regards
> > Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[James Iry]

I don't follow.  Union types don't seem particularly structural to me.
They're the disjunction of other types, and if the other types are
nominative then so is the union of them.  A type like String | Integer
contians all expressions that are Strings or Integers. The idea would be
that you can write the followig.  Here I'm borrowing a touch of Scala syntax
to allow switch on runtime type and use | to indicate disjunction of types.

void foo(String | Integer argument) {
 switch(argument) {
   case s : String => "It was a String " + s
   break;
   case i : Integer => "It was an Integer " + i
 }
}

The types of actual arguments would be checked statically.  The type system
would allow foo("hello") and foo(42) but would not allow foo(false).  For
backward compatibility, the argumenttype could be erased to the least upper
bound (in this case Object) in the bytecode.

Similarly, you could write

String | Integer foo(Boolean flag) {
   if (flag) return 42;
   else return "hello";
}

On Wed, Aug 19, 2009 at 4:21 AM, Ben Schulz  wrote:

>
>
>
> I'm not much of a PLTist, but I'm guessing the reason uions don't make
> it into general purpose, object oriented languages is that they're
> inherently structural. Just a guess though. (The alternative is having
> to check the runtime type and downcast, which pretty much defeats the
> purpose.)
>
> With kind regards
> Ben
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

I may have mentioned it before, but due to very complex reasons I
won't go into here, "catching a checked exception that cannot be
thrown" will most likely become a warning and not an error in java 7.
So, Jess, your #1 gripe may be about to be resolved*.

*) As there isn't an umbrella JSR, let alone some sort of official
list of java 7 changes, this isn't set in stone. It is, however, a
likely requirement in order for a proposal on the coin shortlist
that's been unanimously well accepted to be backwards compatible. We
all know how anal sun gets about backwards compatibility, so for once
you may keep your hopes up.

On Aug 19, 1:58 pm, Jess Holle  wrote:
> I see this as an important change quite apart from the current debate.
>
> Catching an exception that cannot be thrown should be a *warning* not an
> error.
>
> I'm sick of having code stop compiling because someone stopped throwing
> a checked exception!  That should *not* be a breaking change.  There is
> justification for a warning -- something changed that you might want to
> look into and clean up accordingly -- but there's no cause for an error.
>
> This would be my #1 gripe about javac -- bar none.
> //
>
>
>
> Casper Bang wrote:
> > I can confirm this is practice, in fact, the modification to
> > Check.java I described a few posts ago would also allow compilation of
> > code with catch clauses of checked exceptions not really being thrown.
>
> > /Casper
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[James Iry]

On Wed, Aug 19, 2009 at 1:03 AM, Peter Becker wrote:

>
> Interestingly Java's generics allow the dual construction on interfaces:
>
> public  void someMethod(T param) {...}


Yeah, you can do intersection types in generics.  But you can't write

Interface1 & Interface2 foo() {...}

Interface1 & Interface2 x = foo();

Also, note the syntax is different when you create a new type in that
intersection

class Bar implements Interface1, Interface2

Java is maddening with its irregularity.


> I really like the idea of having the anonymous unions/joins and
> considering that the resulting type system should be a complete lattice
> they sound manageable to me -- both for the compiler and the human
> reader. Does anyone know reasons why no language seems to have this
> feature?
>
>
I honestly don't know.  I'm not aware of any languages with that kind of
union type.  Certainly with Scala's pattern matching it would be a prime
candidate for re-extracting union types, but even it doesn't have them.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

> Catching an exception that cannot be thrown should be a *warning* not an
> error.

I totally agree, talk about idiosyncrasies getting in the way of the
job. Anyway, if someone wants to give it a try, grab this build of
javac:
http://82.103.135.236/javac.jar

And notice there's no problem compiling something like this:
public class CheckedExceptionTest{
public static void main(String... args){
Thread.sleep(100); // Throws InteruptedException (checked)
try{
System.out.println("Dum da dum, inside try...");
}catch(IOException e){ // Nothing throws IOException
}
}
}

/Casper
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Jess Holle]

I see this as an important change quite apart from the current debate.

Catching an exception that cannot be thrown should be a *warning* not an 
error.

I'm sick of having code stop compiling because someone stopped throwing 
a checked exception!  That should *not* be a breaking change.  There is 
justification for a warning -- something changed that you might want to 
look into and clean up accordingly -- but there's no cause for an error.

This would be my #1 gripe about javac -- bar none.
//
Casper Bang wrote:
> I can confirm this is practice, in fact, the modification to
> Check.java I described a few posts ago would also allow compilation of
> code with catch clauses of checked exceptions not really being thrown.
>
> /Casper
>   


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

Jess, I think you misunderstand my closure proposal.

It *DOES* have exception transparency. That's in fact exactly what it
has.

You further claim that you can't add exception transparency to
Collections.sort() without making a change to the API. This isn't
true! Read my post again - in my proposal, Collections.sort can be
retrofitted with full migration and backwards compatibility to support
exception transparency.

On Aug 19, 3:58 am, Jess Holle  wrote:
> Reinier Zwitserloot wrote:
> > BGGA's checked exception handling is extremely complex. I don't like
> > it at all.
>
> You can gripe about that, but it is the only thing that really makes a
> code block work "normally".
>
> If you have something like:
>
>     for ( ... )
>     {
>       // some code that throw IOException
>     }
>
> then you'd expect to have to catch IOException or declare "throws
> IOException".
>
> If you don't have exception transparency, then when you use closures to
> do something like
>
>     forEachWombat( ... )
>     {
>        // do some stuff that throws IOException
>     }
>
> You'd get totally different behavior -- which is *not* acceptable in my
> book.
>
> Exception transparency is complex in terms of implementation -- but
> rather simple in terms of usage.  It's really a missing piece of Java
> generics and exception handling in Java as I see.
>
> As for Collections.sort() -- if you want this to allow throwing of
> checked exceptions from the Comparable then this is a dramatic change in
> the contract and, yes, Collections.sort() would have to be
> reimplemented.  There's still a big different between "public T foo()"
> and "public T foo() throws E" -- the former is saying only serious
> unforeseen runtime exceptions could possibly occur in foo() -- that's
> the contract.  That the Comparable contract and changing that is a big
> change.  On the other hand, that's not to say that Callable wouldn't be
> a lot better as "public T call() throws E" than "public T call() throws
> Exception".
>
> --
> Jess Holle
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

Replies inline. The problem is simply this: You think I was trying to
argue against checked exceptions in general. I wasn't. I was arguing
that the checked exception system isn't perfect, and therefore
programmers need to be given a tool to say to the compiler: I know
better than you. Stop whining.

More specific arguments follow below, inline.

On Aug 19, 12:56 am, Peter Becker  wrote:
>
> > Runnable does not let you throw Exceptions. Anyone up for defending
> > this grievous API design? The amount of annoyance that this is caused
> > me is almost limitless.
>
> Where would that exception go?

The same place the RuntimeExceptions thrown by the runnable go. Your
argument only makes sense if Runnable was precluded from throwing -any
and all- exceptions. That's not true. What possible use is there for
someone invoking a Runnable (which after all stands for: I have no
idea what this does, other than run... something...) - to
differentiate between checked exceptions and unchecked exceptions? The
thing threw an exception. It doesn't matter what kind of exception was
thrown.

So, for Thread, that would be: The exception handler of that thread.

>
> It makes some sense to me. The servlet container cares only about the
> fact that the servlet failed, the question why is rather secondary on
> that level. You could also imagine that subtypes are used to distinguish
> the actual problem.

Sure, and if ServletException had a mechanism to specify certain extra
info (such as which error code and message to return), that would be
great stuff. But either way, a servlet container MUST handle *ANY*
exception falling out of a servlet (sneakyThrow, scala, jruby, jython,
any other non-java language on the VM, and mixing class files from
different compile runs can ALL result in a method throwing a checked
exception it didn't declare, so you already have to handle them!)

>
> If you just allow any exception to go through (e.g. by letting the
> methods throw Exception on the API level), programmers will forget to
> handle things they could handle.

Idiots write idiot code. But, okay, I'll roll with your argument: Then
why isn't there a mechanism to escape it? Why can't I say: Nono,
compiler, I did not forget anything, this is what I want. Shut your
yap. You're not really going to argue with me that there is no
inconvenience at all here, right?


>> InputStream.close() throws IOException. Nuff said.
>
> That only proves that exceptions are used badly in the JDK.

That "only" proves? The JDK abuses checked exceptions - That's a
pretty big deal! That's the whole point! That's why the language needs
an escaping mechanism.

The further damage caused by bad coders abusing the escaping mechanism
are, in my opinion, much, __much__ smaller than the potential further
damage that would no longer becaused because the mechanism is
available. The occasional explicitly supressed checked exception that
should have been handled is far less of a crime than code littered
with this abomination:

try {
something();
} catch ( IOException e ) {
   e.printStackTrace();
   //TODO Eclipse auto-generated this. The programmer never looked at
it again, logging to system.err is just about the worst thing you
could do here, and the original programmer only hit quickfix-add try
catch block because he couldn't throw it onwards because he's
implementing a servlet, or a runnable.
}

Sure, an idiot coded that. But we're all idiots some of the time, and
you yourself put 'idiots exist' on the table as a legal line of
reasoning.

>> FilterInputStream and FilterOutputStream's methods throw IOException,
>> but if I feed it a ByteArrayInputStream, or I let it filter into a
>> ByteArrayOutputStream, then an IOException can never happen.
>
> Which could be solved by having safe and unsafe versions of the interface.
>

Do you realize how much code duplication that would require? Exactly
_BECAUSE_ you can't circumvent checked exception checking, you'd
actually have to copy/paste every method. I cannot put into words the
insanity of a system that would _require_ you to copy/paste vast
tracts of code just to satisfy a system that is principally designed
to help code maintainance. Talk about bass ackwards. In practice, you
would most likely implement this by employing a sneaky throw hack.
I can scarcely imagine a better case for enshrining sneaky throwing
into the JLS, than this line of reasoning.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

Yes, it would lose you the ability to parallelize. There may be a way
out of this: Have the following system call:

public class System {
public static  R unsafe(do R closure) { return closure; }
}

The above code would not compile (you may not let a 'do' parameter
escape, but the method is hardcoded into the class library so that it
does in fact compile. You can now remove the 'you may not let your
closure escape' clause, at your own peril, by unlinking it like so:

Runnable youCanStoreMeNow = unsafe(parameter);

The unsafe method would explain in the javadoc that you need to take
on ALL RESPONSIBILITY to transport any long effects back to the
originating thread. So, you need to transport any and all exceptions
that fall out of youCanStoreMeNow back to the originating thread, and
the same goes for the throwables that are used to implement long break/
return/continue (see the BGGA proposal for more details on those).
This is clearly 'here be dragons' territory, but how often exactly
does one write a library for parallelizing things? Maybe like 5 times
in the entire world? Doesn't everyone else just use forkjoin? So, I'm
perfectly allright with having the type system be no help whatsoever
to you in the exceedingly rare circumstance when the rocket scientists
go write this function.

On Aug 19, 8:58 am, Ben Schulz  wrote:
> > I'd much rather have a closure proposal where a method that takes a
> > closure that has tennant's correspondence principle is strictly
> > enforced by the compiler to keep the closure stack-safe. In other
> > words, legal operations are:
>
> > 1. Running the closure,
> > 2. Grabbing info off of the closure object (running its toString or
> > some such)
> > 3. passing it on to another method that accepts closures.
>
> Wouldn't you lose the ability to parallelize? I might want to find an
> element in a collection that satisfies a certain predicate. The
> "first" thread to find one gets to return its findings, the others are
> ignored.
>
> With kind regards
> Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

I can confirm this is practice, in fact, the modification to
Check.java I described a few posts ago would also allow compilation of
code with catch clauses of checked exceptions not really being thrown.

/Casper

On 19 Aug., 13:14, Reinier Zwitserloot  wrote:
> So there IS a bug for that.
>
> I've added a link tohttp://bugs.sun.com/view_bug.do?bug_id=6534270to
> the documentation for lombok's @SupressWarnings, which does the exact
> same thing.
>
> Christian: If you go in with a class file editor and remove the throws
> clauses, the code will continue to run just fine. The validator will
> NOT choke on it. I'm sure of that bit, and I'm almost sure that you
> may catch a checked exception that no statement in the try block could
> possibly throw, as well. javac won't compile such code, but again
> that's just javac, and not a JVM thing.
>
> On Aug 19, 3:06 am, Alex Buckley  wrote:
>
> > I'm slightly embarrassed to admit I'm a fan 
> > ofhttp://bugs.sun.com/view_bug.do?bug_id=6534270
>
> > On Aug 15, 5:56 am, Jeff Grigg  wrote:
>
> > > I like the beauty and simplicity of completely empty catch blocks.  >;->  
> > > OK, some developers, to comply with corporate documentation
>
> > > standards, put comments there.   >;->
>
> > > (Reality is that I'll usually wrap checked exceptions in
> > > RuntimeExceptions at a low level, and then catch Exception at the top
> > > level -- to log it and abort or retry the transaction or user action.
> > > There's a lot of really bad code out there that misuses exceptions and
> > > does exception handling cleanup wrong.  It's a problem!!)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Ben Schulz]

> I really like the idea of having the anonymous unions/joins and
> considering that the resulting type system should be a complete lattice
> they sound manageable to me -- both for the compiler and the human
> reader. Does anyone know reasons why no language seems to have this feature?

I'm not much of a PLTist, but I'm guessing the reason uions don't make
it into general purpose, object oriented languages is that they're
inherently structural. Just a guess though. (The alternative is having
to check the runtime type and downcast, which pretty much defeats the
purpose.)

With kind regards
Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

So there IS a bug for that.

I've added a link to http://bugs.sun.com/view_bug.do?bug_id=6534270 to
the documentation for lombok's @SupressWarnings, which does the exact
same thing.

Christian: If you go in with a class file editor and remove the throws
clauses, the code will continue to run just fine. The validator will
NOT choke on it. I'm sure of that bit, and I'm almost sure that you
may catch a checked exception that no statement in the try block could
possibly throw, as well. javac won't compile such code, but again
that's just javac, and not a JVM thing.

On Aug 19, 3:06 am, Alex Buckley  wrote:
> I'm slightly embarrassed to admit I'm a fan 
> ofhttp://bugs.sun.com/view_bug.do?bug_id=6534270
>
> On Aug 15, 5:56 am, Jeff Grigg  wrote:
>
>
>
> > I like the beauty and simplicity of completely empty catch blocks.  >;->  
> > OK, some developers, to comply with corporate documentation
>
> > standards, put comments there.   >;->
>
> > (Reality is that I'll usually wrap checked exceptions in
> > RuntimeExceptions at a low level, and then catch Exception at the top
> > level -- to log it and abort or retry the transaction or user action.
> > There's a lot of really bad code out there that misuses exceptions and
> > does exception handling cleanup wrong.  It's a problem!!)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Interestingly Java's generics allow the dual construction on interfaces:

public  void someMethod(T param) {...}

I really like the idea of having the anonymous unions/joins and 
considering that the resulting type system should be a complete lattice 
they sound manageable to me -- both for the compiler and the human 
reader. Does anyone know reasons why no language seems to have this feature?

  Peter



James Iry wrote:
>
>
> On Tue, Aug 18, 2009 at 3:13 AM, Peter Becker  @gmail.com > wrote:
>
>
> What I would really like to see is a meet/or/disjunction/union
> operator
> in the type system, with a case-like construct to resolve the
> resulting
> types. Scala has two things that are halfway there (Either, case
> classes), but neither is the full monty.
>
>
> Few type systems have true union types.  The algebraic data types of 
> the ML and Haskell families, for instance, do not allow unioning of 
> types without explicitly creating a new type with its own 
> "constructors".  See Either which in Haskell looks like.  
>
> data Either a b = Left a | Right b
>
> In Scala, Haskell, or SML Either is really just a way of faking union 
> typing in a type system that doesn't do union typing.
>
> Java is actually very unusual in that the small bit of its type system 
> devoted to exceptions basically has union types.  If a method says it 
> throws A,B,C then the union "A,B,C" forms a type and the type "A,B" is 
> a subtype, the type "A,B,C,D" is a supertype.  With regards to 
> declared exceptions on methods Java is covariant.  I know that's not 
> how checked exceptions are normally presented, but that's how the type 
> rules work.
>
> But then Java, as usual, isn't very regular about this union typing 
> business.  You can write
>
> Integer myFunction(File file) throws IOException, MyBusinessException 
> {...}
>
> But if you try to make it "first class" with something like
>
> interface Function {
>   Out apply(In in) throws Exc;
> }
>
> You can't then write something like
>
> new Function {...}
>
> Your first class function has to pick one exception or declare that it 
> throws a common supertype.
>
> Project Coin proposed the ability to catch mutliple exception types 
> with one catch block.  That can be seen as extending union typing just 
> a touch further, but it still doesn't cover exception types as type 
> parameters.
>
> It's not surprising to me at all that Java remains virtually the only 
> language with checked exceptions.  They might be a fine idea, but 
> making them usable and consistent across the language is very tough 
> business.  Checked exceptions are what's called an effects system, 
> which is a way to extend a type system so that functions describe 
> effects they might have beyond computing a value.  Creating an effects 
> system that is usable and consistent across the language is very much 
> ongoing research.  See Disciple 
> http://www.haskell.org/haskellwiki/DDC/EffectSystem, but I warn you 
> it's not for the faint of heart.
>
>
> >



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Ben Schulz]

> I'd much rather have a closure proposal where a method that takes a
> closure that has tennant's correspondence principle is strictly
> enforced by the compiler to keep the closure stack-safe. In other
> words, legal operations are:
>
> 1. Running the closure,
> 2. Grabbing info off of the closure object (running its toString or
> some such)
> 3. passing it on to another method that accepts closures.

Wouldn't you lose the ability to parallelize? I might want to find an
element in a collection that satisfies a certain predicate. The
"first" thread to find one gets to return its findings, the others are
ignored.

With kind regards
Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Christian Catchpole]

Java Exception handling technique number 284. Eat.

http://twitpic.com/efxij

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

> especially small hacks strictly at the parser level

Ok yeah, I know technically it's at the semantic analysis level, but I
always think of the entire front-end (lexer, parser, semantic
analysis) as just the parser. Somewhat simpler than optimizer and
emitter.

/Casper

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

Well actually, Stephen Colebourne has made is real easy to hack on the
Java compiler - especially small hacks strictly at the parser level,
which we're talking about here. If you want to try it check out a
branch of Kijaro, locate the Check.java class and the methods matching
the signatures:

boolean isUnchecked(ClassSymbol exc)
boolean isUnchecked(Type exc)

Short circuit these by always returning true and... voila, no more
checked exceptions.

/Casper

On 19 Aug., 04:24, Christian Catchpole 
wrote:
> I can think of a hack.  But it's not a very nice one and probably has
> limited use.  You compile with "throws Exception" on the method and
> then edit the method signature in the resulting byte code.  Perhaps
> easier than hacking javac.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[James Iry]

On Tue, Aug 18, 2009 at 7:11 PM, Casper Bang  wrote:

>
> Yeah well, it depends how you look at it I suppose. I would also claim
> generics to be a figment of the JVM's imagination, since you can not
> implement Comparable and Comparable due to it
> being an emulated construct at the parser level.


Well, not parser - type checker.  But I know what you mean.  Still, Haskell
has a construct called "newtype" which creates a type whose representation
is exactly the same as another type, but that the type system treats as
compeltely different.  That might allow you to say that inches are a type
distinct from centimeters even though they are both represented with
rational numbers.  The fact that newtypes are guaranteed to be erased for
efficiency's sake doesn't make them any more "figmentary" than any other
type.


> Other languages with
> real generics have no problem with that, in Java all of a sudden you
> are going to need anonymous inner classes as dispatch adapters.



"Other languages...real generics."  C++ of course uses templating to do
polyinstantiation (List is a different class from List) and
mangles the hell out of names so you'd end up with compare_$_Integer and
compare_$_BigInteger functions (or whatever your compiler does with them).
That's all well and good as long as you stick to the same C++ compiler.  But
try to interop with another C++ compiler or another language like C and you
suddenly start wishing all that type information would be erased.  It also
makes it damn hard to extend C++ with something like Java's wildcards or
Scala's existintials and definition site variance. On the JVM side, Groovy
has no problem consuming Java even though parameterized types are way beyond
it, just try creating a dynamic language that so seamlessly interops with
C++.  So, point 1: erasure aids in interop and flexibility.

In Haskell implementations are pretty free to do what they want but they
tend to erase most types, except perhaps in distinguishing what Java people
would call "primitives."  Haskell allows overloading but does it through a
mechanism called a "type class" which is usually (though not always)
implemented with dictionary passing (you can think of this as being somewhat
like passing around a strategy object...sorta). So, point 2: different
language semantics make erasure more palatable, and in Java different
programming styles make it more or less palatable.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

I agree that there is a blurry line between exception and alternate 
return value and as stated elsewhere I would prefer a union type in most 
cases.

In your example the exception should be reasonable exceptional, though 
-- after all people should not try a transfer unless they checked the 
balance first. I guess it all depends on how you define "exceptional".

  Peter


Reinier Zwitserloot wrote:
> Exceptions aren't just for exceptional situations. This seems
> perfectly legit to me:
>
> public class BankAccount {
> public void transferFundsTo(BankAccount other, int amount) throws
> InsufficientBalanceException {}
> }
>
>
> The InsufficientBalanceException is not an exceptional situation. It
> happens all the time, it's an intrinsic part of the design process.
> It's exceedingly likely the calling code will need to deal with the
> SITUATION that the bank account has insufficient funds. However, if
> this method just returned a boolean, they might forget to check.
>
> Proper usage of checked exceptions is actually that the exceptional
> cases (IOException, SQLException...), AND cases where the condition
> isn't particularly exceptional, but it is extremely unlikely that your
> average caller can do anything about it, you ought to be using
> runtimeexception (that would be the vast majority of them). For
> conditions that are NOT exceptional, you should be using checked
> exceptions. Of course, one mans exceptional usecase is another mans
> alternate exit condition, so this is fuzzy logic at best.
>
> >
>   



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Let me just say that I fully agree with this post. I believe most people 
look at the way checked exceptions are used and since that is mostly bad 
they assume the whole idea is bad. Since I can think of nicer solutions 
with checked exceptions for pretty much everything people complain about 
I am not willing to follow their argument.

But I suspect we would need a full library stack written with checked 
exceptions in a better manner to see if they can work.

  Peter


Alexey wrote:
> On Aug 18, 11:03 am, Casper Bang  wrote:
>   
>> On 18 Aug., 16:51, Alexey Zinger  wrote:
>>
>> 
>>> Maybe what this discussion needs is some real-world anecdotes of checked vs 
>>> unchecked exceptions in production environments and how they helped or not 
>>> to save the day.
>>>   
>> I would think it's a fairly real-world anecdote how no other language
>> following Java introduced checked exceptions. Also you will have a
>> much easier job coming up with language guro's against them than for
>> them I think.
>> 
>
> I'm not convinced of that.  So far, most of the complaints come from
> people talking about the imposition checked exceptions create on the
> coder.  There's grumbling of misuse and hiding of exceptions by
> improper logging or catching and ignoring, but not much in the way of
> real-world scenarios.  Not saying those statements aren't grounded in
> reality, but let's throw out some concrete situations to dissect and
> see how they could have been helped.
>
> I'm not a fan of how checked exceptions are used in specific API, JSE
> included, but I'm not against the concept as a whole.  Lately, I've
> been working almost exclusively on web projects, many of them using
> GWT.  Some of those projects were started by my predecessor and, not
> to put the guy down, but there's some horrendous exception handling
> there.  Lots of catch(Exception), inconsistent and often broken
> logging, and all sorts of nasties like that.  Some of the scenarios
> that were very difficult to debug (and still are in some parts of the
> systems) are the ones, where there's use of a 3rd party Excel
> authoring library (jxl as I recall).  Occasionally, the code comes
> across a situation that breaks certain assumptions (unexpected
> formatting, or the like) and those almost inevitably get buried in
> ignored exception catches.  I never get proper time to go through it
> (not that I'm that excited to do it) and clean it up, and so time and
> again we bump into some new extravagant way the system breaks.
>
> Now, one would read this and say, "Aha! -- if only there were no
> checked exceptions, your predecessor would have written his sloppy
> code in a way that would allow those to propagate to the top layer
> (servlet container) and you would have seen it in some log and
> probably on some screen."  Indeed, some of those exceptions are of
> checked variety.  However, the code was written in a manner that
> didn't stand a chance.  He simply assumed there would be no erroneous
> situation and dealt wrote EVERYTHING (file IO, DB, parsing/formatting,
> etc.) under a single try block and figured he'd just log whatever was
> caught in one catch (reuse, right?).  And in fact, there ARE plenty of
> ways to handle these situations based on whatever kind of exception
> might arise.  For instance, multiple formats might be tried on a
> single value before giving up, whereas a general Excel file read
> exception is probably unrecoverable.
>
> And then there's the unintended catching of RuntimeException that's
> sprinkled around there that also just lumps lots of different
> situations into one try/catch.  This one can't be fixed by killing off
> checked exceptions, obviously.
>
> Overall, much of the problems could have been avoided by a better
> internal API design, that would separate different layers of
> functionality into finer granularity and would make it clear to the
> developer how to handle each and every exceptional situation
> differently, while still cleaning up resources when possible.  So I
> don't think simply eliminating checked exceptions would have been the
> answer.  I think both checked and unchecked have their place.
> Remember, that just because Java is the only language with checked
> exceptions, doesn't mean that it's a dead end.  I do think that real
> world implementations have scared some people off the idea.
> >
>   



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

phil swenson wrote:
[...]
> Another issue I didn't mention is checked exceptions pollute the
> interface.  Lets say you have a public API (interface) and add a new
> exception type.  This makes every consumer of your API's code break.
> This violates the concept of having an API "contract".  So with
> checked exceptions either you are forced to 1) violate the contract or
> 2) not throw the exception you want to throw and wrap it in an
> unsuitable exception or 3) use a runtime exception.  3 is best:)
>   
So you are saying it is better to quietly change behaviour than to make 
a change to an API that breaks source compatibility? I certainly would 
not agree to that.
> people are so concerned with not knowing what exceptions are thrown,
> but if you test your projects you will discover when there are
> exceptions that are thrown and you want to handle.  It's a rare
> occurrence.  usually there is nothing you can do about it, so knowing
> that it will be thrown doesn't really help you out.  I mean seriously,
> what do you do when you get a SQL Exception?  it's almost always a
> bug.  and a bug that might not be discovered if you used a checked
> exception and swallowed it.
>   
Sorry, but I call BS on that. SQLExceptions get thrown when the DB 
server is down or in trouble, when the network has issues and possibly 
other reasons that you do not encounter in test environments, so your 
testing won't help. Of course you can let it go through and just let 
your application provide with a generic error message, but there might 
be better ways of dealing with such an issue, in particular if the DB in 
question is not your only data source. For example: if your ads are 
served from a database and that is down, you probably want to fall back 
to some standard display, not a 500. Of course you could do that by 
catching Exception/Throwable around the component responsible, but the 
person integrating the system has to be aware that something can go 
wrong there.

I guess you could just operate on the assumption that everything can 
fail and provide a generic error handler for each component, but I don't 
like this approach at all. In particular I believe that there should be 
parts of your code that do not throw exceptions at all. With checked 
exceptions you can distinguish the ones that do from the ones that don't.

That approach just doesn't work well in Java because JDK libraries 
already throw a lot of Exceptions where they shouldn't (in particular 
the dreaded NPE). But that doesn't seem to allow concluding that the 
idea of checked exceptions is broken as such.

  Peter

> On Aug 18, 4:13 am, Peter Becker  wrote:
>   
>> I still believe that the main reason people hate checked exceptions is
>> that they have been used badly.
>> 
>
> >
>   



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Reinier Zwitserloot wrote:
> Concrete examples:
>
> Runnable does not let you throw Exceptions. Anyone up for defending
> this grievous API design? The amount of annoyance that this is caused
> me is almost limitless.
>   
Where would that exception go?
> Servlets require you to wrap checked exceptions into a
> 'ServletException', which is almost as bad. *ANY* exception caused by
> a servlet is cause to log it and return 500. Why the heck do I need to
> wrap these things? Who is helped by that? Which code has become more
> readable because of that?
>   
It makes some sense to me. The servlet container cares only about the 
fact that the servlet failed, the question why is rather secondary on 
that level. You could also imagine that subtypes are used to distinguish 
the actual problem.

If you just allow any exception to go through (e.g. by letting the 
methods throw Exception on the API level), programmers will forget to 
handle things they could handle.
> InputStream.close() throws IOException. Nuff said.
>   
That only proves that exceptions are used badly in the JDK.
> NumberFormatException is a likely scenario that the calling code can
> usually handle directly, yet its a runtime exception. Making the case
> that IOException ought to be a runtime exception is a lot harder to
> make, so this is quite inconsistent.
>   
I totally agree, not catching NumberFormatException is something I 
consider a code stink -- unless the parsed string is a constant it is 
probably wrong. If it is a constant it begs the question: "Why?".
> new String(whatever, "UTF-8"); throws an UnsupportedEncodingException.
> The JVM Spec says that you aren't a JVM unless you support at least
> the basic set of charsets. UTF-8 is there. So is ISO-8859-1, and so is
> US-ASCII. Thus, that line ought to be throwing a VirtualMachineError
> if UTF-8 is not found.
>   
IMO there should be accessor methods for the common encodings. Again: 
bad API design in the JDK, which we all seem to agree upon.
> FilterInputStream and FilterOutputStream's methods throw IOException,
> but if I feed it a ByteArrayInputStream, or I let it filter into a
> ByteArrayOutputStream, then an IOException can never happen.
>   
Which could be solved by having safe and unsafe versions of the interface.
> Any attempt to use a "closure" (anonymous inner class literal) where
> the "closure" is handed off for immediate processing, right there on
> the spot, nevertheless does not inherit the checked exceptions that
> can legally be thrown on the declaration site. There are a number of
> interfaces which are clearly supposed to be used this way, but its
> impossible to get the API right for these things. This is why the BGGA
> proposal has a very awkward part in it do deal with this issue.
> Designing such interfaces with a 'throws Throwable' clause doesn't
> help; you need to repeat the clause (1) and it would mean that calling
> code has to now deal with all throwables. It's just a disaster. Here,
> imagine you want to sort-in-place a list of files depending on their
> canonical path:
>
> Collections.sort(listOfFileObjects, new Comparator() { public
> int compare(File a, File b) { return a.getCanonicalPath().compareTo
> (b.getCanonicalPath()); }});
>
> Except the above code won't fly; getCanonicalPath throws IOException.
> Even if I wrap this entire line in a try/catch block, that won't help.
>
> How's that for examples?
>   
A nice list of examples where checked exceptions don't work well in the 
JDK. The latter points to an issue between checked exceptions and 
closures in the Java context. Does that in any way imply that the idea 
of checked exceptions is bad in general or that it is impossible to use 
checked exceptions in a positive way in Java? I don't see that yet.

  Peter


>
> On Aug 18, 5:55 pm, Alexey  wrote:
>   
>> On Aug 18, 11:03 am, Casper Bang  wrote:
>>
>> 
>>> On 18 Aug., 16:51, Alexey Zinger  wrote:
>>>   
 Maybe what this discussion needs is some real-world anecdotes of checked 
 vs unchecked exceptions in production environments and how they helped or 
 not to save the day.
 
>>> I would think it's a fairly real-world anecdote how no other language
>>> following Java introduced checked exceptions. Also you will have a
>>> much easier job coming up with language guro's against them than for
>>> them I think.
>>>   
>> I'm not convinced of that.  So far, most of the complaints come from
>> people talking about the imposition checked exceptions create on the
>> coder.  There's grumbling of misuse and hiding of exceptions by
>> improper logging or catching and ignoring, but not much in the way of
>> real-world scenarios.  Not saying those statements aren't grounded in
>> reality, but let's throw out some concrete situations to dissect and
>> see how they could have been helped.
>>
>> I'm not a fan of how checked exceptions are used in specific API, JSE
>> included, but I'm not against the concept as a whole.  Lately,

[The Java Posse] Re: How do YOU handle Exceptions?

[Peter Becker]

Maybe is good if something may or may not be there such in a dictionary 
lookup. The element not being available is a normal occurrence in that case.

In the case of errors it would hide what the actual error was.

  Peter


Michael Neale wrote:
> Or Maybe - (in which case you don't care about the None case, you just
> need to handle it).
>
> On Aug 18, 6:43 pm, Peter Becker  wrote:
>   
>> In Scala you get the Either type. That is superior for most cases where
>> one might use checked exceptions in Java.
>>
>> I have used that style in Java, but you usually don't make friends with it.
>>
>>   Peter
>>
>>
>>
>> Michael Neale wrote:
>> 
>>> What do people think of the scala approach of no checked exceptions -
>>> even checked exceptions are not treated specially by the constructor
>>> (personally, I like it).
>>>   
>>> On Aug 18, 12:55 pm, Christian Catchpole 
>>> wrote:
>>>   
 No, i just let that go up.  I really try to avoid the declare as null
 then set thingy.
 
 On Aug 18, 12:03 pm, Casper Bang  wrote:
 
> You neglect to handle the checked exception declared by
> prepareStatement no?
>   
> PreparedStatement stmt = null;
> try{
> stmt = connection.prepareStatement(sql);
> final ResultSet rs = stmt.executeQuery();
> try{
> while (rs.next()){
> // Stuff...
> {
> }
> finally{
> rs.close();
> }}
>   
> catch(SQLException e){
> // Logging...}
>   
> finally{
> try{
> stmt.close();
> }
> catch(SQLException whoTheFuckCares){
> };
>   
> }
>   
> Really, how many other ways are there to do it I wonder now? (Apart
> from wrapping certain things, like the last try-catch clause in some
> general purpose "closer util"?).
>   
> /Casper
>   
> >
>   



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

On 19 Aug., 04:24, Christian Catchpole 
wrote:
> I can think of a hack.  But it's not a very nice one and probably has
> limited use.  You compile with "throws Exception" on the method and
> then edit the method signature in the resulting byte code.  Perhaps
> easier than hacking javac.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Christian Catchpole]

I can think of a hack.  But it's not a very nice one and probably has
limited use.  You compile with "throws Exception" on the method and
then edit the method signature in the resulting byte code.  Perhaps
easier than hacking javac.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

On 19 Aug., 04:06, James Iry  wrote:
> I really hate phrasing something like this as being a "figment."  That's
> like saying that "short" and "char" are figments of the JVM's imagination
> because it's all just bits.

Yeah well, it depends how you look at it I suppose. I would also claim
generics to be a figment of the JVM's imagination, since you can not
implement Comparable and Comparable due to it
being an emulated construct at the parser level. Other languages with
real generics have no problem with that, in Java all of a sudden you
are going to need anonymous inner classes as dispatch adapters.

/Casper
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[James Iry]

I really hate phrasing something like this as being a "figment."  That's
like saying that "short" and "char" are figments of the JVM's imagination
because it's all just bits.

None-the-less, the answer is that checked exceptions are enforced by Java's
static system and not by the JVM at all.  So Scala, Groovy, JRuby, etc
pretty much just ignore them.

Reinier posted a very clever way to take advantage of the fact that casts to
type parameters aren't checked to effectively cast away the "checkedness" of
an exception without wrapping it, which I'll copy in case you can't find it

public class Sneak {
public static RuntimeException sneakyThrow(Throwable t) {
Sneak.sneakyThrow0(t);
return null;
}

@SuppressWarnings("unchecked")
private static  void sneakyThrow0(Throwable t)
throws T {
throw (T) t;
}

}


It gets used like

public class Test {
public void test() {
throw sneakyThrow(new IOException("this should be checked, but it's
not!"));
}

public static void main(String[] args) {
try {
new Test().test();
} catch (Exception e) {
e.printStackTrace();
}
}
}

It is mildly annoying that you can't catch IOException here because Java
says it can't possibly happen.  Silly Java, we just pervted you so that it
can!

On Tue, Aug 18, 2009 at 6:17 PM, Christian Catchpole <
christ...@catchpole.net> wrote:

>
> People have suggested similar keywords - I don't like the idea of
> wrapping in a RuntimeException, but as we know, checked exceptions are
> a figment of Java's imagination and are simply enforced by the
> compiler.
>
> Why not simply allow them to bubble up as their original exception,
> just remove the need for checking them.
>
> void thing() coverts IOException {
> }
>
> Does anyone know, if you were to remove the throws declarations from a
> method in a class, would the JVM still validate the class file, if the
> method was clearly throwing checked exceptions?  I assume it would
> allow it.  I guess this is how Scala works.
>
> On Aug 19, 11:06 am, Alex Buckley  wrote:
> > I'm slightly embarrassed to admit I'm a fan ofhttp://
> bugs.sun.com/view_bug.do?bug_id=6534270
> >
> > On Aug 15, 5:56 am, Jeff Grigg  wrote:
> >
> >
> >
> > > I like the beauty and simplicity of completely empty catch blocks.
>  >;->  OK, some developers, to comply with corporate documentation
> >
> > > standards, put comments there.   >;->
> >
> > > (Reality is that I'll usually wrap checked exceptions in
> > > RuntimeExceptions at a low level, and then catch Exception at the top
> > > level -- to log it and abort or retry the transaction or user action.
> > > There's a lot of really bad code out there that misuses exceptions and
> > > does exception handling cleanup wrong.  It's a problem!!)
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Casper Bang]

According to Joshua Engel's "Programming for the Java VM", that is not
part of the verification algorithm. I had planned to do something
similar in Kijaro, and instead have NetBeans issue warnings when
neglecting to catch a checked exception - but I never really found out
how to override NetBeans version of javac, I assume its the same
problem Reinier struggles with for Lombok.

/Casper

On 19 Aug., 03:17, Christian Catchpole 
wrote:
> People have suggested similar keywords - I don't like the idea of
> wrapping in a RuntimeException, but as we know, checked exceptions are
> a figment of Java's imagination and are simply enforced by the
> compiler.
>
> Why not simply allow them to bubble up as their original exception,
> just remove the need for checking them.
>
> void thing() coverts IOException {
>
> }
>
> Does anyone know, if you were to remove the throws declarations from a
> method in a class, would the JVM still validate the class file, if the
> method was clearly throwing checked exceptions?  I assume it would
> allow it.  I guess this is how Scala works.
>
> On Aug 19, 11:06 am, Alex Buckley  wrote:
>
> > I'm slightly embarrassed to admit I'm a fan 
> > ofhttp://bugs.sun.com/view_bug.do?bug_id=6534270
>
> > On Aug 15, 5:56 am, Jeff Grigg  wrote:
>
> > > I like the beauty and simplicity of completely empty catch blocks.  >;->  
> > > OK, some developers, to comply with corporate documentation
>
> > > standards, put comments there.   >;->
>
> > > (Reality is that I'll usually wrap checked exceptions in
> > > RuntimeExceptions at a low level, and then catch Exception at the top
> > > level -- to log it and abort or retry the transaction or user action.
> > > There's a lot of really bad code out there that misuses exceptions and
> > > does exception handling cleanup wrong.  It's a problem!!)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Jess Holle]

Reinier Zwitserloot wrote:
> BGGA's checked exception handling is extremely complex. I don't like
> it at all.
>   
You can gripe about that, but it is the only thing that really makes a 
code block work "normally".

If you have something like:

for ( ... )
{
  // some code that throw IOException
}

then you'd expect to have to catch IOException or declare "throws 
IOException".

If you don't have exception transparency, then when you use closures to 
do something like

forEachWombat( ... )
{
   // do some stuff that throws IOException
}

You'd get totally different behavior -- which is *not* acceptable in my 
book.

Exception transparency is complex in terms of implementation -- but 
rather simple in terms of usage.  It's really a missing piece of Java 
generics and exception handling in Java as I see.

As for Collections.sort() -- if you want this to allow throwing of 
checked exceptions from the Comparable then this is a dramatic change in 
the contract and, yes, Collections.sort() would have to be 
reimplemented.  There's still a big different between "public T foo()" 
and "public T foo() throws E" -- the former is saying only serious 
unforeseen runtime exceptions could possibly occur in foo() -- that's 
the contract.  That the Comparable contract and changing that is a big 
change.  On the other hand, that's not to say that Callable wouldn't be 
a lot better as "public T call() throws E" than "public T call() throws 
Exception".

--
Jess Holle


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Jess Holle]

BGGA's exception transparency hinges on disjunctive types, of course...

James Iry wrote:
> On Tue, Aug 18, 2009 at 3:13 AM, Peter Becker  @gmail.com > wrote:
>
>
> What I would really like to see is a meet/or/disjunction/union
> operator
> in the type system, with a case-like construct to resolve the
> resulting
> types. Scala has two things that are halfway there (Either, case
> classes), but neither is the full monty.
>
>
> Few type systems have true union types.  The algebraic data types of 
> the ML and Haskell families, for instance, do not allow unioning of 
> types without explicitly creating a new type with its own 
> "constructors".  See Either which in Haskell looks like.  
>
> data Either a b = Left a | Right b
>
> In Scala, Haskell, or SML Either is really just a way of faking union 
> typing in a type system that doesn't do union typing.
>
> Java is actually very unusual in that the small bit of its type system 
> devoted to exceptions basically has union types.  If a method says it 
> throws A,B,C then the union "A,B,C" forms a type and the type "A,B" is 
> a subtype, the type "A,B,C,D" is a supertype.  With regards to 
> declared exceptions on methods Java is covariant.  I know that's not 
> how checked exceptions are normally presented, but that's how the type 
> rules work.
>
> But then Java, as usual, isn't very regular about this union typing 
> business.  You can write
>
> Integer myFunction(File file) throws IOException, MyBusinessException 
> {...}
>
> But if you try to make it "first class" with something like
>
> interface Function {
>   Out apply(In in) throws Exc;
> }
>
> You can't then write something like
>
> new Function {...}
>
> Your first class function has to pick one exception or declare that it 
> throws a common supertype.
>
> Project Coin proposed the ability to catch mutliple exception types 
> with one catch block.  That can be seen as extending union typing just 
> a touch further, but it still doesn't cover exception types as type 
> parameters.
>
> It's not surprising to me at all that Java remains virtually the only 
> language with checked exceptions.  They might be a fine idea, but 
> making them usable and consistent across the language is very tough 
> business.  Checked exceptions are what's called an effects system, 
> which is a way to extend a type system so that functions describe 
> effects they might have beyond computing a value.  Creating an effects 
> system that is usable and consistent across the language is very much 
> ongoing research.  See Disciple 
> http://www.haskell.org/haskellwiki/DDC/EffectSystem, but I warn you 
> it's not for the faint of heart.
>
>
> >


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Christian Catchpole]

People have suggested similar keywords - I don't like the idea of
wrapping in a RuntimeException, but as we know, checked exceptions are
a figment of Java's imagination and are simply enforced by the
compiler.

Why not simply allow them to bubble up as their original exception,
just remove the need for checking them.

void thing() coverts IOException {
}

Does anyone know, if you were to remove the throws declarations from a
method in a class, would the JVM still validate the class file, if the
method was clearly throwing checked exceptions?  I assume it would
allow it.  I guess this is how Scala works.

On Aug 19, 11:06 am, Alex Buckley  wrote:
> I'm slightly embarrassed to admit I'm a fan 
> ofhttp://bugs.sun.com/view_bug.do?bug_id=6534270
>
> On Aug 15, 5:56 am, Jeff Grigg  wrote:
>
>
>
> > I like the beauty and simplicity of completely empty catch blocks.  >;->  
> > OK, some developers, to comply with corporate documentation
>
> > standards, put comments there.   >;->
>
> > (Reality is that I'll usually wrap checked exceptions in
> > RuntimeExceptions at a low level, and then catch Exception at the top
> > level -- to log it and abort or retry the transaction or user action.
> > There's a lot of really bad code out there that misuses exceptions and
> > does exception handling cleanup wrong.  It's a problem!!)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Alex Buckley]

I'm slightly embarrassed to admit I'm a fan of 
http://bugs.sun.com/view_bug.do?bug_id=6534270

On Aug 15, 5:56 am, Jeff Grigg  wrote:
> I like the beauty and simplicity of completely empty catch blocks.  >;->  OK, 
> some developers, to comply with corporate documentation
>
> standards, put comments there.   >;->
>
> (Reality is that I'll usually wrap checked exceptions in
> RuntimeExceptions at a low level, and then catch Exception at the top
> level -- to log it and abort or retry the transaction or user action.
> There's a lot of really bad code out there that misuses exceptions and
> does exception handling cleanup wrong.  It's a problem!!)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[James Iry]

On Tue, Aug 18, 2009 at 3:13 AM, Peter Becker wrote:

>
> What I would really like to see is a meet/or/disjunction/union operator
> in the type system, with a case-like construct to resolve the resulting
> types. Scala has two things that are halfway there (Either, case
> classes), but neither is the full monty.
>

Few type systems have true union types.  The algebraic data types of the ML
and Haskell families, for instance, do not allow unioning of types without
explicitly creating a new type with its own "constructors".  See Either
which in Haskell looks like.

data Either a b = Left a | Right b

In Scala, Haskell, or SML Either is really just a way of faking union typing
in a type system that doesn't do union typing.

Java is actually very unusual in that the small bit of its type system
devoted to exceptions basically has union types.  If a method says it throws
A,B,C then the union "A,B,C" forms a type and the type "A,B" is a subtype,
the type "A,B,C,D" is a supertype.  With regards to declared exceptions on
methods Java is covariant.  I know that's not how checked exceptions are
normally presented, but that's how the type rules work.

But then Java, as usual, isn't very regular about this union typing
business.  You can write

Integer myFunction(File file) throws IOException, MyBusinessException {...}

But if you try to make it "first class" with something like

interface Function {
  Out apply(In in) throws Exc;
}

You can't then write something like

new Function {...}

Your first class function has to pick one exception or declare that it
throws a common supertype.

Project Coin proposed the ability to catch mutliple exception types with one
catch block.  That can be seen as extending union typing just a touch
further, but it still doesn't cover exception types as type parameters.

It's not surprising to me at all that Java remains virtually the only
language with checked exceptions.  They might be a fine idea, but making
them usable and consistent across the language is very tough business.
Checked exceptions are what's called an effects system, which is a way to
extend a type system so that functions describe effects they might have
beyond computing a value.  Creating an effects system that is usable and
consistent across the language is very much ongoing research.  See Disciple
http://www.haskell.org/haskellwiki/DDC/EffectSystem, but I warn you it's not
for the faint of heart.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

BGGA's checked exception handling is extremely complex. I don't like
it at all.

I'd much rather have a closure proposal where a method that takes a
closure that has tennant's correspondence principle is strictly
enforced by the compiler to keep the closure stack-safe. In other
words, legal operations are:

1. Running the closure,
2. Grabbing info off of the closure object (running its toString or
some such)
3. passing it on to another method that accepts closures.

You can't assign it to another variable, give it to a method that
isn't designed with these restrictions in mind, assign it to a field,
or letting it escape any other way. This is nice for checked
exceptions, as you can just ignore them, it'll all sort itself out,
but it's also nice because with that restriction, you'll never run
into the situation that break / continue / return in the closure
becomes meaningless (those 3 statements become meaningless if the
stack is gone. The for loop you're trying to break out of is long
gone, so, what exactly is break supposed to do? In BGGA you'd get a
TransferException at runtime. Meh).

If the compiler knows FOR SURE that a given closure is always run so
that the stack as it was when you defined it exists, then there's no
need for all the checked exception generics. Any exception you could
legally throw at the point where you defined the closure is legal to
throw in the closure. Example:

Let's say that, purely for arguments sake, "do" as a keyword modifier
of a parameter signals that it can be a closure, and that you can only
make parameters that are SAMs (types that carry exactly 1 abstract
method).

Then you could write Collections.sort as:

public class Collections {
public static  void sort(List list, do Comparator
comparator) {
//do your sort thing.
}


The compiler will then strictly enforce that the sort method doesn't
allow the comparator reference to escape (for its function, there's no
need for that. Contrast to e.g. TreeSet's (Comparator) constructor,
where the comparator must be stored in a field in the treeset, which
would count. You could not stick a 'do' in front of that, the compiler
would refuse to compile that constructor).

Then, you would be able to legally do this in your code:

try {
Collections.sort(someStringList, #(String a, String b) { new File
(a).getCanonicalPath().compareTo(new File(b).getCanonicalPath()) });
} catch ( IOException e ) {
//deal with exception.
}

Please don't get hung up on the syntax, consider it pseudocode. I'm
trying to convey the idea that you're calling code that declares
'throws IOException' (getCanonicalPath does that) in a method
(Comparator.compare) which doesn't even let you declare 'throws
IOException'. The compiler will accept this because it knows, _FOR
SURE_, that the closure is always run so that the stack is intact; in
other words, if an IOException does occur, either something in the
mechanics of Collections.sort handles it, or, if it falls through, the
catch block here will handle it. There's no violation of the checked
exception type system; you can't have an IOException in a place that
isn't prepared to handle them.

In BGGA, the mechanism by which the compiler ensures the checked
exception type system is valid is entirely different: Collections.sort
would have to be changed (which isn't possible, backwards
compatibility being the holy grail that it is, so we'd need a sort2
method. Yich!) to accept a parameter 'E' which is the exception type
(s) thrown by the code block. Because you can throw multiple things,
BGGA has a special syntax for this:

public static  void sort(List list, {T => int throws
E} closure) throws E { /*sort method */ }

Here the compiler just binds E to the appropriate exception type, and
as a result, due to the 'throws E' on the sort method itself, this
propagates out.

Now, BGGA has added quite a bit of complexity to make this work:

 - you have this special 'throws E' syntax, which does a special
thing: It will match multiple exception types. so, if you type "throws
IOException, SQLException", and you're implementing a method with
'throws E' where the E is also specified in the generics type var name
as 'throws E', then E will be [IOException, SQLException], which is
something new - having 1 generics letter mean 2 different types.

 - you need to have rather a lot of 'throws E' everywhere. In that
sort line, you have 3 mentions: In the generics var name, in the
function type, and in the method body. Theoretically it could be
different, but that's the pattern in 95% of all cases: The closure can
throw something, and the method, which operates on the closure, just
wants these exceptions to fall right out.

This notion I have of enforcing a closure to run inside stack is also
present in BGGA; after the first prototype, BGGA's break/return/
continue transparency was considered unwieldy because those terms are
meaningless if the stack is gone. Therefore, 2 closure types exist,
differentiated by the perl cartoo

[The Java Posse] Re: How do YOU handle Exceptions?

[Mario Camou]

The way I normally think about it is, business exceptions are (usually)
checked exceptions. Error conditions are RuntimeExceptions.
-Mario.

--
I want to change the world but they won't give me the source code.


On Tue, Aug 18, 2009 at 19:56, Reinier Zwitserloot wrote:

>
> Exceptions aren't just for exceptional situations. This seems
> perfectly legit to me:
>
> public class BankAccount {
>public void transferFundsTo(BankAccount other, int amount) throws
> InsufficientBalanceException {}
> }
>
>
> The InsufficientBalanceException is not an exceptional situation. It
> happens all the time, it's an intrinsic part of the design process.
> It's exceedingly likely the calling code will need to deal with the
> SITUATION that the bank account has insufficient funds. However, if
> this method just returned a boolean, they might forget to check.
>
> Proper usage of checked exceptions is actually that the exceptional
> cases (IOException, SQLException...), AND cases where the condition
> isn't particularly exceptional, but it is extremely unlikely that your
> average caller can do anything about it, you ought to be using
> runtimeexception (that would be the vast majority of them). For
> conditions that are NOT exceptional, you should be using checked
> exceptions. Of course, one mans exceptional usecase is another mans
> alternate exit condition, so this is fuzzy logic at best.
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Jess Holle]

Reinier Zwitserloot wrote:
> Concrete examples:
>
> Runnable does not let you throw Exceptions. Anyone up for defending
> this grievous API design? The amount of annoyance that this is caused
> me is almost limitless.
>   
Well Runnable is really for cases where run() should eat any exceptions 
other than things like VirtualMachineErrors -- and should not be used 
for anything else.

That said, this is exactly where BGGA's exception transparency should 
come into play -- to allow you to define:

public interface Callable
{
  public T  call() throws E;
}

I will almost certainly get BGGA's proposed syntax muddled here, but the 
important thing here is that call() could throw a precise set of checked 
exceptions and this set would be bubbled up in generic algorithms 
(rather than Exception as in Callable today), e.g.

public  visit( Callable visitor ) throws SQLException, E;

or some such.  The actual list of checked exceptions emanating from 
visit would be SQLException, IOException, MalformedURLException if E was 
IOException, MalformedURLException.

One can still wrap the exception at any point along the way, of course, 
but one is not /forced /to arbitrarily do so at various points as one is 
today just because of the imprecision of a generic algorithm's declaration.

--
Jess Holle


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[The Java Posse] Re: How do YOU handle Exceptions?

[Reinier Zwitserloot]

Exceptions aren't just for exceptional situations. This seems
perfectly legit to me:

public class BankAccount {
public void transferFundsTo(BankAccount other, int amount) throws
InsufficientBalanceException {}
}


The InsufficientBalanceException is not an exceptional situation. It
happens all the time, it's an intrinsic part of the design process.
It's exceedingly likely the calling code will need to deal with the
SITUATION that the bank account has insufficient funds. However, if
this method just returned a boolean, they might forget to check.

Proper usage of checked exceptions is actually that the exceptional
cases (IOException, SQLException...), AND cases where the condition
isn't particularly exceptional, but it is extremely unlikely that your
average caller can do anything about it, you ought to be using
runtimeexception (that would be the vast majority of them). For
conditions that are NOT exceptional, you should be using checked
exceptions. Of course, one mans exceptional usecase is another mans
alternate exit condition, so this is fuzzy logic at best.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---