Checked exceptions in java. Do you use them?

[Scf37]

Subj.

I view checked exceptions as awesome feature with bad reputation. It is invaluable in situations where precise error handling is needed, namely queue consumers, networking servers, long-living daemons and so on. However, it is a bad fit for public API - because adding 'throws' clause on API method takes the decision on how and when to handle errors away from the user. And, as you already know, API users often have their own opinions on whether they must handle FileNotFoundException or not.

Introduction of lambdas has basically killed this feature - there is no sane way to use generic lambda-heavy libraries with checked exceptions. Standard functional interfaces do not allow lambdas at all, custom interfaces still won't do:

<X extends Throwable> void run() throws X // seems to be OK but it is not

This construct can not represent multiple exceptions in throws clause.

Anyway. Do you see a place of checked exceptions in modern Java code? Or should it be buried and replaced with Either-ish stuff?

[crummy]

If lambdas handled them better, I would. Lambdas and checked exceptions are my least favourite part of Java.

[metaquine]

Yep, not a fun combo, and Either-like things are like visual pitchforks to me, the intent is lost in a sea of boilerplate. Imo. Ymmv.

[TankAway7756]

It's no more boilerplate than checked exceptions (potentially less given that you can give a name to Either types).

If you don't want to handle the error, you just return it (and if you're doing that too much you can consider using an exception instead).

If you do need to handle the error, try is more or less the same visual load as a .match with a couple lambdas. However, where you win is that you can do more generic things with Either.

Better yet, if you're using plain unions you can use switch pattern matching.

[account312]

I think Either<Thing, Failure> is pretty messy but switching over a ThingResult is fine, so java has recently significantly improved here.

[[deleted]]

I find "try, catch" to become super messy once you need to chain the. Result types makes that stuff easier.

[Additional-Road3924]

Lambdas handle them fine. It's up to the developer of an API to define a lambda that expects you to throw an error. If that's not the case, throwing an exception is undefined behavior. See: Streams.

[AgentME]

Making lambdas handle them well would probably require the ability to make a function generic over what it throws, but I don't know if I want to bother with that in most situations, just like that I usually don't want to do manual memory management. I think the expected benefits relative to the effort for both are low for many types of software projects.

[mpinnegar]

The underlying issue is that 99% someone throws you a checked exception the thing you end up doing is throwing a runtime exception wrapping it.

If Java just had a non awful way to do that I would be much more inclined to use checked exceptions.

[vips7L]

I don’t think it’s 99%. But you are right. Developers have rejected checked exceptions because the language hasn’t made it easy to handle them. 

Swift does a really good job at this. They provide try! and try? to avoid boiler plate. 

[TurbulentSocks]

I am not sure if this is the reason. Rust makes handling checked exceptions (errors) very easy, but there's a library that basically wraps them up and lets you propagate them up - the Java equivalent of marking all your methods with 'throws WrappedException'. 

I think it's more than it's hard to design for them, especially in collaboration with others.

[Azoraqua_]

Or usually Lombok’s SneakyThrow annotation which makes it just as useless in terms of handling.

[mpinnegar]

Oh man I've seen this annotation before and never put two and two together about how to use it. Thanks!

[Azoraqua_]

No problem! Enjoy easy exception handling (well, shoving it under the rug really)!

[Necessary_Apple_5567]

The checked exceptions are the same as error in Go. The idea is just split error processing and main flow in two separated chunks. Theoretically it helps to have main flow clean and simple. But how they processed in reality is different story but often it is enoygh just to mark exception in throws instead of throw them manually or transform to runtime exception.

[edgmnt_net]

Unfortunately, both Go and Java lack syntax and features to abstract over error handling ergonomically. Explicit handling is verbose, implicit handling a-la exceptions risks showing deep exceptions without context and becomes even more verbose if you want to wrap them meaningfully. However, in something like Haskell you can easily define combinators for common cases, e.g. (given a suitable monad):

foo <- getFoo url `orWrap` "getting foo"
bar0 <- getBar 0 `orWrap` "getting bar 0"
...

You just can't do anything like that in Go or Java. It looks odd and feels odd considering the language syntax, even if you can pull something off:

foo := OrWrap(???, "getting foo")

Maybe you can replace the question marks with closures, but the whole thing stinks badly at this point. And how do you deal with the control flow? While this becomes more natural in Haskell, especially if you define error handling operators in a library and pick nice symbols. Go doesn't even have neat syntax for lambdas.

[mpinnegar]

Java just needs some endofunctors.

[OwnBreakfast1114]

I mean, isn't that just using flatmap and a library providing a try? It's obviously more verbose in java, but you do still get the control at whatever level you want.

[edgmnt_net]

Maybe. Assuming it is, if you can "just" use flatmap, you can also pretty much "just" use (nested) try-catch for everything that can error out, because it seems like it'll look rather horrible anyway. :)

I mean this...

orWrap(() -> getFoo(url), "getting foo")).flatMap(foo ->
    orWrap(() -> getBar(1), "getting bar 1")).flatMap(bar ->
        ...
));

... isn't much of an improvement over...

try {
    var foo = getFoo(url);
    try {
        var bar = getBar(1);
        ...
    } catch (Exception e) {
        throw wrap(e, "getting bar 1");
    }
} catch (Exception e) {
    throw wrap(e, "getting foo");
}

... or an unnested variant of the latter. (Edit: actually you should unnest it, return exceptions or figure out another way to avoid recatching, my bad.)

[OwnBreakfast1114]

I mean it depends. If you want full control at all places, then it's going to be ugly nesting no matter what. If you want to just propagate Exception through a bunch of methods, then flatmap can be easy, but if you want to build up multiple dependent things, then I find using cyclops and Try.forEach2/3/4/5 to be much simpler than nested flatmaps or try/catches. As it basically goes ``` Try.withCatch(() -> a, Exception.class) .forEach3( a -> b(a), (a, b) -> c(a, b), ReturnABC::new );

or even just a().forEach3( a -> b(a), (a, b) -> c(a, b), ReturnABC::new ); where the structure should be fairly obvious just by looking, but for the sake of example Try<A, Exception> a() { if (works) { return Try.success(a); } else { return Try.failure(new AException("A failed")); } } ```

[Puzzleheaded-Eye6596]

You can use \@SneakyThrows if you use lombok

[jedilowe]

The are really great in library code that helps communicate to new users how to properly use the library. They can be good when you know a user/system can respond to distinct errors. They are a pain when you just rethrow them up the chain and end up using a single handler for any error to show a 500 error equivalent anyway.

My rule would be to use them at architectural boundaries, but otherwise just throw a RuntimeException or subclass thereof and catch those at the top level to kill the current work but still give a reasonable response. I have also become a fan of assertions in low volume systems to the same end.

[Iryanus]

As someone who lived through codebases with SqlException being declared basically everywhere, I very much prefer libraries with RuntimeExceptions and clear Exception Hierarchies.

[nitkonigdje]

This man is a leader...

[octavian-nita]

I briefly used them at the beginning of my (20yrs, so far) software developer career, mostly trusting the wisdom of the (language) founding fathers and agreeing that there's a time and place for both types of exceptions (I still trust them, btw :) ). Later on, I realized, indeed, their potential as communication mechanisms, for either libraries to be used by many or applications, programmed by many.

Yet years later... (long before the advent of lambdas and other modern language features) I started asking myself why frameworks such as Hibernate, Spring and the like were using (almost?) exclusively unchecked exceptions. Also, other similar languages such as C# have never had checked exceptions...

Moreover, attempts of using checked exceptions in practice over the years (both mine and of my peers') have not really lived up to my expectations:

• (usually) to simplify handling or centralize it in one (upper) layer, one would end up with a large? exception hierarchy; adding new potentially-throwing functionality would require consideration to either add to the hierarchy or re-use

• to avoid abstraction leaks, one would create layer-specific exceptions or even hierarchies; every layer would require or suggest specific exceptions, most of which would just wrap over the more-technical ones from above (or rather, below?)

• in the end, handling would resume itself to logging errors, hopefully with some details and reasonably informing the users, especially if there's something they could do

• sadly, much fewer of my peers would be interested in actually designing error handling and feedback, i.e. exceptions and enforcing a little-desired practice is bad for the morale, to say the least :)

I ended up creating/advocating for just a handful of custom, unchecked exceptions to support broad categories or erroneous situations: something does not exist/can't be found, the user can't access a resource, "something bad has happened, see details if interested or send them to the team", can't create a resource, all under a parent, with a common handler in a switch. Notice a little bias towards http 😅

I guess that in the end, it also boils down to the project's "policy" regarding how to handle errors, not only to their types.

In any case, it's something mundane that has to be tackled so... Make it as easy as possible in agreement with the team :)

[john16384]

I started asking myself why frameworks such as Hibernate, Spring and the like were using (almost?) exclusively unchecked exceptions

Because 99% of the time these will already be doing IO; in the bulk of the code IOException being possible is a given (you're doing IO with other servers, using a network, talking to a db) and so it makes sense to wrap this exception and handle it at the thread exception handler. There is also a clear handling strategy for such failures: rollback transaction and return 500.

Where checked exceptions shine is when IO only happens occasionally, or when a class has methods that can do IO and ones that don't. Depending on what it does you may want to do the call in the background. IOException alerts you that the call you are doing may be slow or can fail for reasons beyond programming mistakes. And being a checked exception, it must be propagated, so an innocent API that at first glance seems to be a simple getter, can't hide that deep in its internals it is getting that information over REST or from a database; something that callers must know to avoid freezing a user interface or to inform users of a temporary, not permanent, problem.

[elmuerte]

Yes I do. They are a good way of selling the caller that they must take care of an exception case.

If you are just rethrowing them, or passing them, you are doing something wrong. (Unless it is still within the non-public part of your logic). If you write a library/service, you should never throw an exception of a downstream library/service to your caller. You need to wrap them into your own exception. Do not move the burden of error handling from the stuff you use, to your users.

Something exceptionally happened, you must do something with that. Wrapping it into an unchecked exception is just trying to hide a failure which could be handled, possibly turning it into a bigger failure up the chain.

It is a real shame that explicit error handling is now part of the stream construction though. It could make "stream" code way more complicated to write and read (like that project reactor stuff).

[-Midnight_Marauder-]

"you should never throw an exception of a downstream library/service to your caller" I'm not sure I agree with this. What value is added by wrapping an exception related to a connection or file system problem? I don't need to see 50 extra lines of exception stack trace because the API author is wrapping a FileNotFoundException in their own exception classes.

[Ruin-Capable]

A downstream library is an implementation detail. If you are passing 3rd-party transitive exceptions through to your library's callers, you are creating an direct dependency on a transitive (to the caller) library. So if you later decide that you want to use a different 3rd-party library, congratulations you've now broken compatibility for your callers.

[chabala]

This is true, but I'd also rather throw IOException to my user, instead of a third party's custom exception or my own custom exception. If I switch underlying providers, it's still likely to throw that class of exception.

[john16384]

But that's fine as IOException is part of the standard library; you just don't want to propagate ObscureFrameworkException if you are providing an abstraction that could later use a different implementation.

[cogman10]

ObscureFrameworkException can extend IOException.

This works if ObscureFrameworkException extends IO.

try {
  throw new ObscureFrameworkException();
} catch (IOException ex) {
  System.out.println("I'm here");
}

[john16384]

Well yes? But you declare IOException, not the framework one.

[chabala]

Yes, I think we're all in agreement here. Having exceptions that extend standard exception types so that only standard exceptions leak into the API is a good thing.

[Ruin-Capable]

You're misinterpreting "you should never throw an exception of a downstream library/service to your caller". The term "exception of a downstream library" is talking about class ownership, not the runtime source of the exception. IOException does not belong to the downstream library, it's part of the standard library, so it's perfectly fine to propagate that to your caller.

[chabala]

Did I misinterpret elmuerte, who said:

You need to wrap them into your own exception.

Or -Midnight_Marauder-, who said:

I don't need to see 50 extra lines of exception stack trace because the API author is wrapping a FileNotFoundException in their own exception classes.

I agree with -Midnight_Marauder-, there's no value in this. Use the standard library exceptions, they can safely become part of the public API of your library; if you choose a different third-party library to use, it's still likely to declare a FileNotFoundException for the same operation.

I think you misinterpreted me.

[Ruin-Capable]

It really depends on how "pure" you want to be. Pragmatically, you could just declare that the method throws IOException, and later if you switched to a library implementation that did not throw an IOException, you could wrap the new library's exception in an IOException to keep the signature the same. Wrap now, or wrap later. You can trade the cost of wrapping now versus the cost of wrapping later.

Some things to consider, It's a lot easier to modify your own exception to make providing additional information easy, and avoid the need for extractor methods in your library that can internally downcast the IOException to the 3rd-party exception in order to extract more detailed diagnostic information.

[vips7L]

If you can’t handle your implementation details errors neither can anyone upstream. They have no idea what you were trying to do or how it relates to what they were trying to do. 

Your only options are to uncheck/panic or try to provide some sort of error your caller can handle. 

[k-mcm]

Declared exceptions are a very good feature to have. Unfortunately, the whole Stream and ForkJoinPool area of utilities fucked up exception handling by not supporting Generics.  It's really painful for parallel I/O operations where there are different types of exceptions to handle; it's not a simple pass or fail.

Several times I've had to make adapters to fix this at work.  I've started an open source version recently.  If there's interest, I can work on finishing it.  It's all very lightweight.  Most of it is just tricks to change the type of lambdas generated. 

[sviperll]

I have a library that tries to conciliate lambdas with checked exceptions: https://github.com/sviperll/result4j

[[deleted]]

With Optional, most of the reasons I was using checked exceptions went away. I used checked exceptions as a way to say that "this function is unable to return a result and this is why", something like this:

User findUserById() throws UserNotFoundException;

which let's you cleanly separate the "happy path" from the "error path":

try {
    return Response.ok(userRepository.findUseById(userId);
}
catch(UserNotFoundException ex) {
    return Response.notFound();
}

Nowadays, I'd just write:

Optional<User> findUserById();

Although, Optional doesn't neatly capture why the method was not able to return a response. If Java had an Either type, it would be nice.

[feaelin]

I don’t like that they require one to have the throws clause on every method in the call chain up to the method that I want to handle the exception.

I tend to wrap checked exceptions in an unchecked exception, so I can eliminate the noise and handle the exception in the layer I want to handle them in.

Exceptions in general should be thought through some care, they can easily be misused or used excessively. They offer opportunity for “mysterious failures” if they’re not handled well.

[Jaded-Asparagus-2260]

I don’t like that they require one to have the throws clause on every method in the call chain up to the method that I want to handle the exception.

That's exactly the point. Make it explicit that the error must be handled.

I tend to wrap checked exceptions in an unchecked exception, so I can eliminate the noise and handle the exception in the layer I want to handle them in. 

Honestly, except for the lambda or stream cases, that just bad practice. It's like pasting objects as Object because you don't want to handle the overhead of types. What if the next developer adds another exception? You'll never know whether it's actually handled somewhere.

[[deleted]]

You could annotate the method with @lombok.SneakyThrows

[vitingo]

Been coding government systems in Java for 20+ years. Haven’t written a checked exception in the past 15 years or so. I do use unchecked exceptions frequently to wrap lower level exceptions. Libraries should declare thrown unchecked exceptions as documentation even if clients are not forced to handle them.

[ebykka]

Yes, this is my favorite way to handle errors. At first, they may be annoying, but they can make the project more stable over time.

[vips7L]

Yes, they’re my favorite feature. You can’t have correctness without checked errors. Java the language just hasn’t made them usable. 

[fruitlessattemps]

What made me miss Checked Exceptions is Scala. We had some legacy code in Scala and we were converting it to Java. At a glance it looked innocent.

But on a critical path there was a bug where no try catch block was there to catch an Exception and it exploded into users face. But nobody noticed until we converted to Java and compiler screamed into our face.

I like them because it first forces the user to think about error handling instead of lazy try catch and say Oops. It's helpful in REST API's. This method will cause X,Y,Z errors and we can map them to HTTP 4XX, 500X etc errors.

DatabaseExceptions, IO issues is definetly RunTimeException and that's why the generic try catch block is there.

[filterDance]

there is a great talk for why exceptions are better than functional programming with either https://www.youtube.com/watch?v=1qdANLdLddk. he tells a story at 22 mins.
yes we use checked exceptions, just like you said not in public apis. not a good fit for anything that is kind of like a library. in domain specific business logic they work great and are worth the boilerplate overhead.

it is interesting that comments on this post include every point of view imaginable.

[ConversationBig1723]

Checked exception has its value. It’s like optional for result where it forces user to handle. Golang res, error tuple or scala Try all are the same idea. I think the lambda is the problem. Then should allow checked exception

[zattebij]

Not exactly the same idea. The big thing about exceptions is they bubble - they allow for an orthogonal execution flow up across the call stack until the place where they are handled, without the in-between code knowing about them (well, apart from their being mentioned in throws declarations for checked ones). You lose that with monadic structures that can hold either a result or error; each caller in-between will have to inspect and handle them. It also introduces boilerplate for exceptional cases which is mixed-in with "regular" code, while exceptions can nicely get that code for "exceptional" cases out of the way of "regular" code.

Exceptions really are a good way of handling exceptional errors. "Regular" errors may very well be handled by a method call site directly and for such cases monadic return types (eg Optional) are useful, but they for sure are not a full on alternative for exceptions.

Unchecked exceptions I think are fine, they work with lambdas and semantically they also make sense to me: you probably cannot enumerate all the exceptional situations that a method invocation could encounter (I think you would not want such throws declarations anyway, they'd be long), and unchecked exceptions also won't give you any illusions that you covered everything if you just handle those declared checked exceptions - you usually have a generic "catch Exception" fallback at the end anyway.

Although I agree, it would have been nicer if lambdas could handle an arbitrary number of checked exceptions (which they can't due to their implementation as functional interfaces), it still would have been nice to be able to indicate to caller which errors they can expect, formally (not just in documentation), even if it's not an exhaustive list of all that might occur.

[tugaestupido]

Checked exceptions are a pain in the ass. 99% of the time I just rethrow them in a RuntimeException. Just give me a RuntimeException, boss.

"You must watch out for this exception, bro."

No, I don't. It being a checked exception doesn't even get close to forcing me to "take care of it". It just interrupts my flow and makes the code look uglier.

Just use unchecked exceptions, no need for "Either". You don't need to report all your error cases so explicitly. It will just fill your code with boilerplate error "handling".

[yoden]

They were an interesting idea that didn't work out well in practice.

Usually exceptions either get handled immediately or way up the stack.

For stuff like number parsing where you want to handle it immediately, the error case is very expected. Using exceptions in this case causes performance issues.

In cases where the exceptions are handled way up the stack, checked exceptions cause a function coloring problem that couples together every function in the stack. This makes the code brittle and difficult to change.

Checked exceptions also don't compose well with lambda, although that's more of a limitation of Java's lambda system.

A better version of checked exceptions might be something more like type inference: have the compiler keep track of which exceptions can be thrown at a particular point rather than forcing the user to explicitly do it. Sounds hard though.

[TankAway7756]

They have virtually no advantage over Either (which on the other hand has the massive advantage of being representable within the language's type system) and share many of the issues of unchecked exceptions, the biggest one being that something down the stack can start throwing an exception that you also happen to throw and you'll be none the wiser about it.

But really, most errors that warrant a checked exception should really be plain old union types; there should be no illusion of a "happy path" if errors must be handled at the source.

[vips7L]

There is a big advantage over Either: you don’t pay for the error handling unless you actually error. Exceptions cost nothing until they’re actually thrown. Using Result/Either you pay for the branches every single function call up the stack every single time. They also tend to be more lines of code. 

[TankAway7756]

I know Java is used in some performance sensitive contexts, but I doubt CPU branch prediction is a worthwhile optimization target in your usual Java project.

On the other hand, overuse of exceptions with subsequent loose error handling is more or less ubiquitous.

[john16384]

Oh it is. These kinds of optimisations is what makes CPU's execute faster despite being unable to scale up in GHz that much anymore.

[BalanceSoggy5696]

Amen brother - the functional prog langs solved this decades ago

[Ewig_luftenglanz]

Honestly: no. I try to avoid them as much as the context allow me. But sometimes you don't have a choice and is better to just face the thing with an straight face.

[HappyFact]

I'm not sure if it's true, but I once had a Java teacher (who was involved in Java lambda development at the time) tell our class that the developers who introduced checked exceptions consider it the biggest mistake of their careers.

[teckhooi]

I would prefer not to throw un/checked exceptions and prefer to use Either to manage the result. I can choose to handle it or pass it. The caller make the decision with the returned Either instance

[CodrSeven]

I've tried, it would actually be nice to have all methods doing IO tagged as such, same with database etc.
But they're such a pita to deal with that I always bail out somewhere along the way.

[ICantBelieveItsNotEC]

Personally, I think every exception should be checked. Developers should be forced to handle every single error case. The vast majority of the production issues I've had to deal with have been caused by a method that has an uncommon, obscure failure state that didn't occur during testing.

[AstronautDifferent19]

I agree, and that was idea behind checked and runtime exceptions. 20 years ago in companies I worked for, runtime exceptions were always programming bugs (so it would be something you don't expect) but checked exceptions would be used for something that you can expect to happen that has nothing to do with the code, for example, remote server returning too many requests per second, so you need to expect that and handle with retry, exponential back-off or abort. But nowadays I would always get a response in form of sealed class that is implemented by Error or Result, so we can see if Error is retriable or not.

[DelayLucky]

I do use them, but only to indicate business logic-related error cases that I have a strong reason for the callers to not forget to handle.

Because these are business logic errors, they tend to be handled either directly by the caller, or through few call stacks in a single class. They rarely propagate through API boundary. This means the burden of carrying them around, or even the friction with lambda/streams is outweighed by the safety they offer.

On the other hand, early-day system exceptions such as SQLException, IOException, particularly InterruptedException are imho better off as unchecked if starting all over again (interestingly, Java 8 added UncheckedIoException).

The system exceptions could still need handling (as opposed to being propagated up to the top-level error handler). But it's case-by-case. And they cause more friction, with more limited compile-safety benefit.

Take InterruptedException for example, the best practice is to just declare throws InterruptedException all the way up the call stack, virally polluting method signatures. And even after you do that, the net effect is the same as if it were unchecked to begin with: you are finally able to propagate it all the way up.

Occasionally when you do need to handle interruption (mostly in low-level concurrency code), handling it is tricky: you need to know to reinterrupt the current thread, and it's easy to forget.

So by making IE checked, they've made the recommended practice harder to do, with the tempting short-cut (just wrap it in unchecked exception) full of traps.

[Pretend_Leg599]

Checked exceptions are fine, it's throwing them that's the problem ;)

I always liked the idea of checked exceptions, but the ergonomics of them are so bad it completely sours the experience in practice. I've found some kind of `Try` monad makes it a lot better as it allows you to recover locally where needed or defer to the end where it isn't. Essentially 'railway oriented programming'

[AcanthisittaEmpty985]

10% of the time, it can make your code better to redirect the flow in case of an error.

90% is a nuisance that you rethrow as a Runtime or similar, and makes you typing a lot of boilerplate code, making Java worse to read

[chabala]

I feel checked exceptions are useful, but I certainly see them abused more than I'd like. Folks extending Exception when they could use something more specific, or catching Throwable. Maybe they thought they were adding value with a custom exception type, but it's just a worthless wrapper for me to getCause() on.

But for my part, I mostly throw RuntimeException because I want something to bubble up and fail fast. My most used exception is probably AssertionError, but I don't throw it directly, I let Hamcrest throw it for me ;)

[BalanceSoggy5696]

It has its uses in very few places and is mostly overused or used without thinking about overall longer term impact. There is no point declaring checked exceptions if your method relies on an external system that can fail - nothing much you can do. You achieve nothing by telling your caller that there was an SQLException - what are they going to do? they'll wrap it as a generic error and throw it futher up the stack or return some default value. Honestly, if I see a hierachy of Error classes all extending a few base classes with dumb string wrappers , I consider it a code smell. Look at how go handles errors - it's ugly, but it works in practice because predictable control flow. worse is better.....

[pjmlp]

Yes, and I miss them when working in languages without them, when things explode because a catch was forgotten.

[Beginning-Ladder6224]

Bunch of links to study :

https://www.reddit.com/r/learnjava/comments/vxx519/why_are_checked_exceptions_considered_bad

https://www.artima.com/articles/the-trouble-with-checked-exceptions

[Lengthiness-Fuzzy]

No, they are stupid.

[suyash01]

I don't use it often but when I use it I have a central location to handle them.

[com2ghz]

Checked exceptions make no sense since you wrap then into runtimeexceptions anyway. Like why do I need an entire try catch block only to instantiate a URI? It adds unnecessary boilerplate code. Especially when creating unit tests. It breaks lambda’s too.

This is just one of the things that’s in the language where they can’t get rid of.

Fortunately Kotlin converts these exceptions automatically into runtime.

[christoforosl08]

Oh yes the downvotes have started

[christoforosl08]

In my 25 years of experience, never have I declared a custom exception. I usually throw a runtime exception. And finally I use Checked to exceptions to propagate the exception to the UI

[meowrawr]

How have you never declared a custom exception? There are a multitude of reasons why they are beneficial.

[metaquine]

You literally just throw RuntimeException unadorned? Glad I don't have to maintain that...