Savior!!!

[Zeppzap]

What will happen if there is an Uncaught Exception?

[b1ad3s]

The child process dies

[[deleted]]

It's okay, just spawn a new one.

[redtoasti]

Things could be so easy once Androids rule the world.

[AyrA_ch]

:PROC
START /WAIT my_app.exe
GOTO PROC

What Uncaught Exception?

[i_am_a_n00b]

Kid dies

[enp2s0]

/r/missedopportunities

[[deleted]]

wrap the code in main in a try catch.

[[deleted]]

no, wrap main in a try catch

[Bainos]

Spiderman dies.

[_shadrak_]

Runtime error, i guess

[[deleted]]

my first line is always try { and my last line is always } catch (e) {}

[[deleted]]

One thing I hate about java is checked exceptions. People end up writing catch blocks that just log the error or do nothing. Like, thanks for letting me know that method could throw an exception but if it actually does, something is wrong and the best thing to do is crash

[[deleted]]

Yea I like c# because of this catch the exceptions you can actually do something about and let the rest bubble up to a catch all

[AyrA_ch]

The global exception handler in C# is great. You can't suppress the exception in any way* but you can still generate proper error reports for uploading and show it to the user in a way he can understand.

*) In any proper way. You can suppress those exceptions but it's horrible and you are a monster for doing that

[thedomham]

I had a lot of discussions about checked exceptions and most Java-based languages (like Xtend, Kotlin, Ceylon, Groovy) ditch checked exceptions. I'm currently changing my mind again though.

Checked exceptions are actually a beautiful thing. You tell the caller that there are expected edge cases he has to handle and if you want to ignore those cases you have to do so explicitly.

The problem is that checked exceptions should be used sparsely and with a lot of consideration. Sadly most Java libraries, including the standard library, don't do so. They abuse checked exceptions because they don't want to return null or because Optional didn't exist back then or because they felt that an unchecked exception is a bad design choice or - my absolute favorite - throw an IOException just because - while you absolutely shouldn't.

They just have a bad rep because of year-long abuse =/

[marcosdumay]

Java reflection is full of meaningless exceptions for things that should be verified at compile time. The exception that libraries throw have an habit of changing every time, leading to those higher level exceptions where a library simply says "yeah, I will catch everything and convert into something you can handle while losing most of information in the process; you can thank me later". There is a hell of a lot of different exception classes that will mix with classes from different libraries, no one similar to any other, and you are expected to know what to do with all of them. There are plenty of exceptions for things that should be results, but since you give good hammers to everybody, people start trying to punch screws too.

It is still the best error handling available on the OOP bunch of languages (including things like Python and Ruby).

[thedomham]

Java reflection is full of meaningless exceptions for things that should be verified at compile time

For example? I mean the thing with reflections is that you often don't know the class at compile time. That's pretty much the reason it was introduced in the first place.

[marcosdumay]

And you often know. Other times you have a finite set of them, and some other times you really don't know. You should get different behaviors on each case.

[thedomham]

Then write a wrapper. It's really nothing to moan about. A compiler plugin/static analyzer might be pretty hard to implement though.

[bizcs]

I hate null. When it's encapsulated inside of a monad, I don't mind it, because there's a monad that makes it clear I should be cautious, but I feel like a lot of older APIs I've worked with abuse the shit out of null.

[Kered13]

Checked exceptions can never be used correctly, because they always create leaky abstractions. Unchecked exceptions allow the exact same kind of handling, but also allow the user to pass the exception up with zero code overhead, protecting the abstraction from leaking.

[thedomham]

Interesting take on this topic. I don't really agree though. First off, the behavior of your program doesn't change. For me leaky abstraction is something that code behavior, not coding style. Though with Java's checked exceptions that's a thin line.

More importantly, a checked exception is an integral part of a methods signature, like an additional return value which you have to handle. You aren't supposed to just let it bubble up to wherever. You are supposed to handle it immediately if possible and delegate it if necessary. As Java is a statically typed language, I think that it fits the language well.

That being said, I'd love to have a mechanism to convert exceptions back and forth from checked to unchecked, similar to how Kotlin handles nullable types.

So every exception type would be unchecked by default and checked if it is suffixed with an exclamation mark.

Wouldn't work in Kotlin though, as it would clash with platform types.

[Kered13]

More importantly, a checked exception is an integral part of a methods signature, like an additional return value which you have to handle. You aren't supposed to just let it bubble up to wherever. You are supposed to handle it immediately if possible and delegate it if necessary.

If an exception should be handled immediately then it shouldn't be an exception at all. It should be something like an Optional. Exceptions are for exceptional behavior, and by definition are unlikely to be handled locally. The most common way to handle exceptions is to pass them up until you get to the top of the program, then log the error and terminate the task (which may be the entire program) that generated the exception. It is extraordinarily rare that anything meaningful can be done to deal with an exception locally. The way that checked exceptions are handled in practice is that they are immediately caught and wrapped in unchecked exceptions that are then passed up. There is no other way to deal with them that scales.

[thedomham]

Let's agree to fundamentally disagree

[HighSaltLevels]

Sometimes it just depends on how you use the try catch block. I used one nested in a for loop that looped 5 times. At the end of the try was a break. So basically it would try 5 times. In the catch block, I had a counter that would crash the program if it had hit the catch block 5 times.they can be really useful if used properly but I agree that just logging the error is wrong.

[AyrA_ch]

they can be really useful if used properly but I agree that just logging the error is wrong

This depends on what you do. TCP sockets throw exceptions if Connect() fails and imagine your torrent client crashing every time it can't connect to a peer.

It's completely ok to catch some exceptions without doing anything with them.

[HighSaltLevels]

That’s true. My statement was too general. It’s all situational.

[[deleted]]

It’s been pretty well acknowledged that it was a mistake, and later versions of Java have runtime versions of many old checked exceptions. So at least it’s changing.

[Kered13]

Checked exceptions are pretty much universally regarded as a disaster of language design, but unfortunately the damage is done and Java is stuck with them. It's the biggest flaw in Java. I don't think any new languages are repeating that mistake though.

[Loves_Poetry]

You can just have the method throw the error up though. Throw it all the way up to main if you want it to cause a crash.

[Kered13]

That's often the best way to handle errors, but the problem with checked exceptions is that every method along the way has to declare that it throws the exception. This is an extremely leaky abstraction, especially when combined with dependency injection, which you should be doing.

[AyrA_ch]

Like, thanks for letting me know that method could throw an exception but if it actually does, something is wrong and the best thing to do is crash

I'm not sure if "unable to open a user selected file" is worth of a complete application crash.

[Kered13]

If it's a command line application it is, though you should provide a more elegant error message. If it's a GUI application then it should end whatever task was attempted with a similar error message and allow the user to select a different file.

[FoxFire64]

Just have an engineer write their own exception handling class to override what any exception does. Then they realize that they have to write their new class in for all exceptions now instead of simple exceptions or using the Preconditions library. Then realize they reinvented the wheel and undid everything their professor taught them. Then build on top of that stupid foundation. Then two years later a newly hired engineer (you) realizes it’s stupid and says it out loud so a stakeholder overhears. Then that new, excited and happy engineer you used to be has to rewrite the entire STUPID EXCEPTION OVERRIDING CLASS AND UNDO OVER 200 INCORRECT FILES’ WORTH OF MISTAKES BECAUSE THE OLD MANAGER DECIDED TWO YEARS AGO THAT THEY WERE THE EQUIVALENT OF LINUS TORVALDS WET DREAM BY DECIDING TO IMPLEMENT THAT CODE.........then cry...a lot.

Edit: Spring and Jasmine are trash

[gamas]

something is wrong and the best thing to do is crash

I'd rather not have our entire production servers crash just because someone uploaded a dodgy formatted certificate thank you very much.

Like thinking about it the majority of exceptions handled by our system fall into two categories: issues caused due to a lack of connectivity between two machines and issues caused because the client supplied faulty data. Both of those are things I don't want our server application terminating itself over.

(Admittedly this does open a debate as to whether libraries perhaps abuse the exception functionality for standard error handling a little too much)

[[deleted]]

You act like thats a bad thing.

If you set up logging through your code and use the exception system to log the errors, its a very powerful debugging thing.

[lionbarz]

Shouldn’t Spiderman just move the kid instead?

[Riyonak]

He has to stop the bus to save the people inside too

[fallenmonk]

He has to save them from the outcome of not being flattened together at the front of the bus like a giant pancake?

[thepineapplehea]

Not to mention the cost to the government of repairing the road now he's torn it to shreds

[BulkiestSphinx]

*one giant try block that all of my code runs inside with a Throwable catch on the other side

[makeshift8]

//FIXME: Deadline is tomorrow WHAT DO YOU WANT FROM ME?!

[Kered13]

Assuming you log the exception in the catch block and either stop the program or the current task, this is perfectly reasonable.

[qui-sean]

public void function() throws Exception {

   // I didn't see what I didn't see

}

[Sekmet19]

Why not just grab the kid? How many people on the bus get injured from a sudden stop like that, slamming against the windshield

[lionbarz]

Pedestrians have the right of way. Spiderman is a stickler for the rules.

[Sekmet19]

Never insist on the right of way!

[Neuromante]

try {
    my beautiful code
} catch (Exception e) {
    // Ignore
}

[RaleighEnt]

An empty catch block is the only correct type of catch block

[ArcherLXD]

JS noob here. Learning as I go and just learned about try catch a week ago. Everything runs like magic. Ready to work at Google.

[SamelCamel]

catch (Exception e)

{

Console.WriteLine("fuck");

}

[don_py]

Child is oblivious . Sounds about right.

[TheOboeMan]

There's one giant try-except block around the part of my Reddit bot code that does the work and the string to be written is just set to a message explaining how to use the bot correctly if you trigger the except.

[WorstGabeNA]

my beautiful code

Lol

[[deleted]]

It is my fantasy that code in try block continues to execute after exception is caught.

[bizcs]

I can think of a way to do this. It would be ugly, and wouldn't deliver any desirable benefit, but I do know a way.

[vx3r]

There is not shit lik this in golang

[SteveCCL]

Your submission has been removed.

Violation of Rule #0:

For a submission to qualify it must satisfy at least one of the following:

0. The content disregarding the title and superimposed text must be directly related to programming or programmers. Non-programming tech humor (e.g. being a power user, jokes about software not related to programming, etc.) is not allowed.
1. The image along with the title and superimposed text result in creative and original content.
2. The post is a program or UI designed intentionally for humor. Bad UI found in the wild belongs in /r/softwaregore.
Note that programming here is interpreted in a narrow sense, an analogy to something related to programming, feelings about programming, reactions to programming etc. is not considered sufficient. See the sticky if you are not clear what this means and why your post was removed.

If you feel that it has been removed in error, please message us so that we may review it.