We Keep Coding

Why should you wrap checked exceptions in lambda's in an unchecked exception?

I've been a Java developer for about two years now and if there's one thing I really love about the language it's the stream API. It makes my code so much more fluent, consise and readable.
The one thing that bothers me though is how exceptions are supposed to be handled when working with lambda's. I've read several articles on the subject and have seen several questions on StackOverflow.
The general consensus seems to be that you have to wrap the method call to catch the checked exception and rethrow an unchecked exception instead.
(like so:https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams )
But I've yet to read or understand why this is a good idea. The advantage of checked exceptions is that the caller knows what to expect. I was taught that whenever you want to enforce business rules, checked exeptions is the way to go. Unchecked exceptions should be reserved for those cases where the application cannot recover from the exception. So why did they pretty much force us to use unchecked exceptions when working with streams? This seems like a big flaw at first glance, right?
I'm currently writing a SOAP webservice and a big advantage is that all possible business faults that can be thrown are well defined. The client can respond accordingly to the exceptions being thrown.
Throwing a runtime exception would cause the client to receive a SOAPFaultException not knowing what the heck went wrong or how to handle it.
I could use a global exception handler and catch all the possible RTE's (given I don't forget some) and then once again rethrow them as one of the checked exceptions defined in the XSD/WSDL.
But I have a hard time enough convincing my senior colleagues of the benefits of functional programming and telling them to wrap their checked exceptions in unchecked exceptions, only to turn them back into checked exceptions is definitely not going to help my plight.
So why is catching checked exceptions in lambda's and wrapping them in unchecked exceptions considered the good way to do it? There are very few other scenario's where we would really catch a checked exception and throw an unchecked exception.
So why is it considered to be the good option when working with lambda's?
Is it really because it is the only possible way to do so (safe for a few dirty workarounds like Lombok's #SneakyThrows) given the language's limitations?
And then how are you to handle all these unguided missiles?

Why should you wrap checked exceptions in lambda's in an unchecked exception?
Short answer: because you have to. (Pretty much.)
So why did they pretty much force us to use unchecked exceptions when working with streams? This seems like a big flaw at first glance, right?
Without going into the history and the debate about whether checked exceptions were or were not a mistake ...
The handling of exceptions in streams and lambdas is actually a direct consequence of the general design of Java exceptions and exception handling. The latter cannot be changed: it would be too disruptive for Oracle's existing Java customer base. Therefore we are stuck with this for the foreseeable future.
Is it really because it is the only possible way to do so (safe for a few dirty workarounds like Lombok's #SneakyThrows) given the language's limitations?
Yes, it is the only way. Whether it is a good way or not.
And then how are you to handle all these unguided missiles?
One way is to simply let the unchecked (or sneaky checked) exception propagate. In most cases the application or thread will crash, and you can use the stacktrace in the log file to find / fix the root cause. This assumes that the original checked exception is not "expected" and therefore not really recoverable.
If you are trying to make your application recover from the checked exception:
For a wrapped exception, you can catch RuntimeException then use ex.getClass() and ex.getCause() to decide what to do.
For a sneaky checked exception, you can catch Exception and use instanceof to discriminate the (expected) sneaky checked exceptions from the unchecked ones.

Should I ever use exceptions in java if I can solve problem without them?

Are exceptions like goto in c don't use it if you don't have to or is it OK to use them as much you want to, and why?
Are they hard on CPU, memory or something else?

You should regard exceptions as a tool that can help you make good software design, similar to data encapsulation (private fields with Getters/Setters), inheritance, interfaces, etc.
The idea of the exception concept in Java is to give you a good way of moving error handling to a spot in your code where it makes most sense. When you face a problem at some line of code, then the first thing you should ask yourself is: Should this method/class that I have here be responsible for handling the problem, or is there a better, more high-level place in my software that should handle it? If you find the latter to be the case, then throwing an exception to that higher-level instance is good design.
Think of it as this: Let's say someone at your work place gives you a pack of bills and tells you to add up the total billing amount. And then in the middle of the bills you find another document that is something completely different. In that case, it would make more sense to go to the person who gave you the pack of documents and let them handle it, instead of deciding for yourself what to do with it, because you may not know what exactly to do.
Example in software: Let's say you have a method that expects a birth date and should calculate the age of the person (difference to current date). But then you find that the given date is incorrect, for instance because it is in future. This method should not deal with fixing the problem, because you might not know how. Is this program a console program and you should print an error, or will it have a GUI? So, you throw an exception to a higher level of the application that knows if there is a GUI or not, and thus whether to print an error to console or show a dialog in the GUI. That's just a simple example, but I hope you get what I mean.
To sum up: Exceptions are nothing "bad" in Java. When used properly, they are a good thing that help you avoid putting responsibilities into objects that they shouldn't have.

...don't use it if you don't have to or is it OK to use them as much you want to...
According to Joshua Bloch's Effective Java:
Exceptions are, as their name implies, to be used only for exceptional
conditions; they should never be used for ordinary control flow.
In order to fully understand this, let's take a look on Java exception. In Java we can find three types of exceptions: checked exceptions, runtime exceptions, and
errors.
Checked exceptions: as their name implies, they should be checked/treated by the developer. Moreover, the compiler forces you to handle this exceptions by try...catch or propagating them upwards by marking the method with throws keyword. These kind of exceptions usually extend the builtin `Exception' class.
Unchecked exceptions: in this group enter both runtime exceptions and errors. The difference between checked exception and unchecked exceptions is that the compiler does not forces you to handle unchecked exceptions. Since they should be used to indicate programming errors, usually it is a good idea to not catch them at all and focus on preventing them. Errors are reserved for use by the JVM to indicate critical failures which usually prevent your program to be recoverable. All of the unchecked
exceptions should subclass RuntimeException class.
So, to give you a response to your first question, it is OK to use exceptions as long as it makes your code readable, more understandable. Moreover, you should be able to deal with exceptions, since compiler will force you to do so. This does not mean that you should throw exceptions whenever you want.
Now let's talk about performance. To repeat myself, exceptions should be used in exceptional cases. This means that they are not as performant as a single if..else would be. Using them wisely, you wont really notice a performance hit, overusing them can cause problems. Exceptions should never be used for control flow (gotos can be used for). In case of memory, every exception creates a new object, which should contain some information about the exception itself. Creating many exceptions would result in occupying more memory, but I don't think that this can be a problem nowadays.
Should I ever use exceptions in java if I can solve problem without
them?
It depends, and is up to you on deciding against or in favor of them. Usually, exceptions are thrown to notify the lack of something (example: no money to withdraw from a credit card, non-existent file to open, etc.) In order to avoid using exceptions in these cases, it is a good idea to return on Optional of something.
This answer is based on Joshua Bloch's Effective Java book. For more information I suggest reading the Exceptions chapter.

Java proper use of exceptions and cost

I'm trying to take a slightly stricter approach to coding this class. Instead of my usual cowboy coding style, creating as I go, I'd like to first lay out the methods, the variables, the comments... all that jazz.
So now here is the concept of the exception.
Should I think "What are all the things that could possibly go wrong in this function?" and throw an exception for each (if existing ones aren't descriptive enough then create a new one)? It seems this is the most precise option.
Should the line of thinking be "These are things that will probably go wrong, I'll throw a general exception for everything else."
How about "Nothing will probably go wrong, I don't need to throw an exception, worse case I can throw a runtime exception in the off chance something does go wrong..."
What I'm worried about here is the performance of the error handing. Ideally I could imagine Java just converting those exceptions into nice little if statements or some sort of jump statement. I imagine this could only cost one operation or so.
I can also imagine Java creating a circus 20 calls deep for the sake of abstraction, maybe then they are costly and I should pretend I'm coding in C all over again?
I wrote the question in a silly way since its more fun for both of us that way, but its a serious question. I'm sure there is some balance, maybe a rule of thumb or ten. How do you think about exceptions?
Edit: I'm not suggesting I use exceptions for processing. What I am talking about is the number and preciseness of the exceptions (How specific an error, perhaps?).

Exceptions ARE more expensive at run time, so should not be used as a part of "normal" processing.
Exceptions are for exceptional circumstances. Anticipated failures should not generate an exception. For example a user providing invalid input (wrong password, invalid zip code, etc.) should not generate an exception.
Exceptions are for bugs, and serious unrecoverable system failures.
Note that JDBC's use of exceptions is poorly designed (according to the principles I'm suggesting).

How convince other developers not to ignore Exceptions?

Recently I encountered a bug in an application I took over from another developer. I debugged for the reason and over an hour later I realized, that the problem wasn't the code producing the exception, but some code executed before this returning wrong data. If I dived into this, I encountered the following:
try {
...
} catch (XYException e){}
If the Exception would have been propagated (a change I did), I would have found the reason for the bugs in a few minutes, as the stacktrace had pointed me to the problem. So how can I convince other developers to never catch and ignore exceptions in this way?

Simple rule of thumb: catch exceptions if and only if you have a meaningful way of handling them. Do whatever you need to do at your workplace to propagate this simple rule.
By utilizing tools such as PMD, you can even enforce this in the development environment of all your developers. EmptyCatchBlock (first rule under Basic Rules) is a rule that does exactly what you need. You have some more out-of-the-box rules for exceptions if you need better control on exception handling.
Nevertheless, in my experience, enforcing the use of tools such as PMD is never a substitute to proper development practices and developer education.

Start BadHumour:
Add a silent critical
exception into the code that causes
the application to shut down, and
let them sit and cry trying to find it
for about an hour - Then educate
End BadHumour
The simple rule is simple: Use exceptions for exceptional circumstances. Anything else is silly and wasteful. Compare swallowing of exceptions to eating candy coated razor blades. They may taste nice now, but wait until they start to be digested. (Coding Test system vs. Debugging Live system)

Simple point - have the lead developer declare that. Catching an exception and swallowing it without reason is equal to sabotage and should lead to recursion against the developer (i.e. talk i nHR about his attitude).
As Yuval said, catch exceptions only if you actually do something sensible. let things bubble up if you dont know what or how to handle them. POSSIBLY wrap them in other exceptions IF expected (i.e. a DAL may throw a DataLayerException so that higher up levels can handle all that stuff in one try/catch, but it would not handle something unexpected).
it is a ridiculous way to catch exceptions and swallow them.

The same way you convince other developers to follow any sort of best practice. This particular anti-pattern is a fairly common (and extremely painful!) one, but there's countless other examples of bad coding practices that are probably at least somewhat common among your team members.
In order of difficulty in getting started, here's some recommendations I've seen used effectively in the past:
Talking to the developer, pointing out the problem, and describing how it caused problems for you. The simplest solution - not always effective, and it will only work for that one developer, but it's better than doing nothing.
Public shaming. I've worked in places where we had a "Wall of Shame" with various coding horrors from our project, along with the developer who wrote them. It's really important that this is done in a lighthearted way, and it's really something I wouldn't advise just starting without getting everyone on board, but it's a fun way to point out issues like this.
Reading groups. If you have the means to get a lunchtime reading group started at your office, I highly recommend it. Coding issues like this would be addressed extremely well by a reading group going through "The Pragmatic Programmer".
Code reviews. Again, not the simplest thing to get started if you're not a team lead, but it's absolutely worth a suggestion to yours if you aren't one. If you are a team lead, you should have started code reviews yesterday.

Point them to this link http://www.ibm.com/developerworks/library/j-jtp05254.html an article which explains when to check or uncheck or throw or catch :)

One nice feature I like about the VS.Net debugger is that you can tell it to break when any exception is thrown. It isn't something you would turn on all the time, but can help when you're trying to hunt down a particular bug. I wonder if the same feature exists for Java, since it is an environment very similar to .Net. I think this problem shows up more in Java than it does in .Net however, because Java requires you to handle exceptions, or to at least mark your method as throwing the same exception (AFAIK). So, if you are required to handle it, a lot of bad developers will just swallow it, because they have no idea how to handle it, or what to do with it.
None of this really helps you stop bad developers from doing bad things. I think the best thing you can do, is to do code reviews. Encourage coworkers to look over the list of check-ins to ensure that things are done correctly. With a good source control system, this can be done pretty easily. And human eyes can catch things that computers can't. A computer would be able to delete an empty catch block, but humans can catch a whole lot more antipatterns.

The title does not match the example. In the example the exception is not ignored but handled in a nasty way (this is sometimes referred to as exception swallowing). For this particular malady I recommend static code analysis and bonus/salary reduction.

Charge the time against the developer concerned, or the module concerned, rather than yourself, or your own module.

There are some subtle ways to that (each of those being subjects to discussions)
Make all your application's Exception RuntimeException subclasses. This way, there is no try/catch in your application, and you can easily see (at the thread level) what problème broke the thread. Unfortunatly, this has no effect on the developper that wrote this code block precisely to get rid of an exception he didn't bother to manage.
Use Checkstyle, or an other static code checker, to ensure no empty catch block exists in your application. Unfortunatly, this do not works when no continous integration process exists in your team (since errors notification won't go to the developper responsible for them).
Provide default catch template code with a sensible value (like a logger.log(Level.WARN, "something went wrong here", e)) allowing user to not have to worry about exception management, however having a reasoably good code.

Why are Exceptions not Checked in .NET?

I know Googling I can find an appropriate answer, but I prefer listening to your personal (and maybe technical) opinions.
What is the main reason of the difference between Java and C# in throwing exceptions?
In Java the signature of a method that throws an exception has to use the "throws" keyword, while in C# you don't know in compilation time if an exception could be thrown.

In the article The Trouble with Checked Exceptions and in Anders Hejlsberg's (designer of the C# language) own voice, there are three main reasons for C# not supporting checked exceptions as they are found and verified in Java:
Neutral on Checked Exceptions
“C# is basically silent on the checked
exceptions issue. Once a better
solution is known—and trust me we
continue to think about it—we can go
back and actually put something in
place.”
Versioning with Checked Exceptions
“Adding a new exception to a throws
clause in a new version breaks client
code. It's like adding a method to an
interface. After you publish an
interface, it is for all practical
purposes immutable, …”
“It is funny how people think that the
important thing about exceptions is
handling them. That is not the
important thing about exceptions. In a
well-written application there's a
ratio of ten to one, in my opinion, of
try finally to try catch. Or in C#,
using statements, which are
like try finally.”
Scalability of Checked Exceptions
“In the small, checked exceptions are
very enticing…The trouble
begins when you start building big
systems where you're talking to four
or five different subsystems. Each
subsystem throws four to ten
exceptions. Now, each time you walk up
the ladder of aggregation, you have
this exponential hierarchy below you
of exceptions you have to deal with.
You end up having to declare 40
exceptions that you might throw.…
It just balloons out of control.”
In his article, “Why doesn't C# have exception specifications?”, Anson Horton (Visual C# Program Manager) also lists the following reasons (see the article for details on each point):
Versioning
Productivity and code quality
Impracticality of having class author differentiate between
checked and unchecked exceptions
Difficulty of determining the correct exceptions for interfaces.
It is interesting to note that C# does, nonetheless, support documentation of exceptions thrown by a given method via the <exception> tag and the compiler even takes the trouble to verify that the referenced exception type does indeed exist. There is, however, no check made at the call sites or usage of the method.
You may also want to look into the Exception Hunter, which is a commerical tool by Red Gate Software, that uses static analysis to determine and report exceptions thrown by a method and which may potentially go uncaught:
Exception Hunter is a new analysis
tool that finds and reports the set of
possible exceptions your functions
might throw – before you even ship.
With it, you can locate unhandled
exceptions easily and quickly, down to
the line of code that is throwing the
exceptions. Once you have the results,
you can decide which exceptions need
to be handled (with some exception
handling code) before you release your
application into the wild.
Finally, Bruce Eckel, author of Thinking in Java, has an article called, “Does Java need Checked Exceptions?”, that may be worth reading up as well because the question of why checked exceptions are not there in C# usually takes root in comparisons to Java.

Because the response to checked exceptions is almost always:
try {
// exception throwing code
} catch(Exception e) {
// either
log.error("Error fooing bar",e);
// OR
throw new RuntimeException(e);
}
If you actually know that there is something you can do if a particular exception is thrown, then you can catch it and then handle it, but otherwise it's just incantations to appease the compiler.

The basic design philosophy of C# is that actually catching exceptions is rarely useful, whereas cleaning up resources in exceptional situations is quite important. I think it's fair to say that using (the IDisposable pattern) is their answer to checked exceptions. See [1] for more.
http://www.artima.com/intv/handcuffs.html

By the time .NET was designed, Java had checked exceptions for quite some time and this feature was viewed by Java developers at best as controversial controversial. Thus .NET designers chose not to include it in C# language.

Fundamentally, whether an exception should be handled or not is a property of the caller, rather than of the function.
For example, in some programs there is no value in handling an IOException (consider ad hoc command-line utilities to perform data crunching; they're never going to be used by a "user", they're specialist tools used by specialist people). In some programs, there is value in handling an IOException at a point "near" to the call (perhaps if you get a FNFE for your config file you'll drop back to some defaults, or look in another location, or something of that nature). In other programs, you want it to bubble up a long way before it's handled (for example you might want it to abort until it reaches the UI, at which point it should alert the user that something has gone wrong.
Each of these cases is dependent on the application, and not the library. And yet, with checked exceptions, it is the library that makes the decision. The Java IO library makes the decision that it will use checked exceptions (which strongly encourage handling that's local to the call) when in some programs a better strategy may be non-local handling, or no handling at all.
This shows the real flaw with checked exceptions in practice, and it's far more fundamental than the superficial (although also important) flaw that too many people will write stupid exception handlers just to make the compiler shut up. The problem I describe is an issue even when experienced, conscientious developers are writing the program.

Interestingly, the guys at Microsoft Research have added checked exceptions to Spec#, their superset of C#.

Anders himself answers that question in this episode of the Software engineering radio podcast

I went from Java to C# because of a job change. At first, I was a little concerned about the difference, but in practice, it hasn't made a difference.
Maybe, it's because I come from C++, which has the exception declaration, but it's not commonly used. I write every single line of code as if it could throw -- always use using around Disposable and think about cleanup I should do in finally.
In retrospect the propagation of the throws declaration in Java didn't really get me anything.
I would like a way to say that a function definitely never throws -- I think that would be more useful.

Additionally to the responses that were written already, not having checked exceptions helps you in many situations a lot. Checked exceptions make generics harder to implement and if you have read the closure proposals you will notice that every single closure proposal has to work around checked exceptions in a rather ugly way.

I sometimes miss checked exceptions in C#/.NET.
I suppose besides Java no other notable platform has them. Maybe the .NET guys just went with the flow...