*prevents your app from crashing*

write a class or 2 before making sure everyone knows youre a clueless retard user.

Just use structs

what if the exception handler throws an exception?

catch {
throw;
}

you can't just do that

...
catch {
...
catch {
throw;
}
}

you can, it will throw the exception to the next catch block

Why don't people just into proper input validation and error handling, never used exceptions

you've never used a method that could raise an exception?

>throw new RuntimeException(ioe)

Scala exception handling is fantastic. If you start writing functional code, you can even eliminate exceptions and rely on the type system entirely.

or pattern matching

I probably use them too often and instead of implementing a proper handling I just use a try and catch statements. Although everything I do is pretty much single use anyways

Coroutine-scoped crashing is the best pattern.

stop that

Do literally anything involving web crawling. I'll wait.

>user makes a mistake entering input
>HahahahahaHAHAHAHA NOT MY PROBLEM YOU FUCKING NORMIES
>program hangs, eats memory, crashes OS
>valuable data is now gone

Glad we did this instead of handling errors.

you mean *crashes the program because someone didn't handle the file-not-found scenario*

for me, it's go's check/handle.

extremely based i love using try catch for shit that i dont want to take the time to debug

Sounds based as fuck, fuck the user.

Handling exception is writing good code, every method should do one thing and if it can't it's some other method's problem.

Opposite view: just don't handle exceptions, unless it's necessary. Make the program crash early and loud. Fail-fast instead of fail-safe.
Every method should do one thing but by handling exceptions you make some method do two things: the normal thing it does, and handle exceptions to the normal thing.

Exceptions are good in theory for situations that are actually exceptional, like running out memory or trying to write to read-only memory. Something more common and likely to happen, like user input error, is easily expressed a simple value with no downside. It makes the program easier to comprehend because there won't be some badly documented library function that's buried five layers deep throwing some obscure exception. Honestly fuck python.

sensible view: most "errors" are expected "errors" and should be dealt with there and then, not stupidly passed off to a distant exception handler to fail with error message or (worse) make the program crash

ITT: People using mediocre languages without Result types.

Attached: 1561655497954.gif (640x358, 2.21M)

kys yourself

>have to test every function which returns an error
>this function returns a value, but that one returns an error, but what does this one return?
>every damn call becomes an if...then
>error handlers...error handlers every where
>if muhERR then exit function x1000 to tear down the stack
>"error values are superior"
Please do the needful and kill yourself pajeet.

You can implement a result type in almost any language. If it’s a template language it’s double easy

Well you're supposed to call other methods in the try block to do the one thing that your method does. The catch block also calls other methods. So I guess it's a fine line.

underrated post

I just click the launch windows debugger button and hit resume and the application keeps going.

It's often a good idea to move error checking up ahead earlier.
For instance, a division function could return an error on zero or instead only take a divisor known not to be zero (or just return a junk value on zero, that's perfectly reasonable too.)

Consider,

subtype Positive is Integer range 1 .. Integer'Last;
function Divide (Numerator : Integer, Divisor : Positive) return Integer is
begin
return Numerator / Divisor;
end Divide;

This is probably not good for a division function (I'd go with the returning junk option for this case) but for other cases could be useful.

this
it's not that hard to go if function() != 0 {error handling}

>instead of proper error handling i want every function call to potentially crash my program
This is a characteristic of pajeet languages like Java as well, please do the needful sir.
>every call becomes an if..then
l o l

this. you should only catch on external access (foreign closed code, device io) the rest should be exposed and debugged

I wonder who hides behind this
|>
|3

exception
when others then
...
end

Attached: 1494779596478.gif (360x202, 347K)

foo, err := GetFoo()
if err != nil {
return err
}
bar, err := DoBar(foo)
if err != nil {
return err
}
err := DoBaz(bar)
if err != nil {
return err
}
is this good code to you?

No, it's Go.
let foo = get_foo()?;
let bar = do_bar(foo);
do_baz(bar)?;

Phone input took out the ? from do_bar, outside right now, you get the idea. Haskell has nice operators for this too, Go just happens to have world-famous ugly error handling.

Here's your error handling bro.
try {
poo.inLoo();
} catch(Throwable t) {
t.printStackTrace();
}

>catch
>printstacktrace
>application ends

Attached: ZP8KMen9zB-12.png (300x250, 26K)

have fun wrapping your entire standard library in an extra abstraction layer so you can actually use your custom result type consistently

try {
//shitty code
catch (Exception e) {
return null;
}

Java is fucking comfy.

Poojeet tier error handling

I literally have a try/exception block wrapped around a the whole monitoring app I manage at work. I log all errors and add fixes as bugs appear :^)

was about to say this lol

So this is the code that's in the New Vegas Anti Crash mod? I have heard about exception handling before.

I don't understand. Why are there 2 seperate arrow lines?

Attached: 1E09F14548834CF79B710272CB3BDFCA.png (465x418, 239K)

Not every language is like c or go bro.

separate*

fpbp