i do understand that exceptions are used to address any unexpected event, but i can't wrap my head around what makes them special? like im a bit confused when should i throw one? what are considered as unexpected events? How do we decide that? idk if my question makes sense, but im not comfortable with throwing exceptions it could be due to not using them much or my lack of experience in that matter. Please do ping me if this makes sense.
#Exceptions
ocean zinc
unkempt sinewBOT
<@&987246399047479336> please have a look, thanks.
unkempt sinewBOT
<@&987246399047479336> please have a look, thanks.
While you are waiting for getting help, here are some tips to improve your experience:
tame knoll
Well, I don't have a proper answer to your question, but I'll share my opinion about exceptions:
They are not special. For me, exceptions are a billionaire mistake, like nulls. You can for example, instead of throwing an exception, return a invalid state, like a null or a -1 int (in a context which this int is always positive). Exceptions are basically a "second return type", when you don't have any other way to flag a invalid state (for example, if returning null can mean something). In Rust, we don't have exceptions, we have Result<T, Err>, and that's possible (or will be possible, I dunno) to do in Java
talking about "unexpected events", in Rust we represent them as panics, the difference is they are unrecoverable, while Java's exceptions can be recovered through a try/catch, so if I today would write a code in Java, I would use exceptions as unrecoverable exceptions, and just use try/catch when i'm dealing with JDK ecosystem and it's not possible to write proper code without a try/catch, and I would never use a try/catch when calling my own functions, because my exceptions are always meant to be unrecoverable. And for cases when there's no other way I can represent a invalid state, I would use a Optional<T> or (if it's possible today) use Java's version of Rust's Result, if this is not enough, I would restructure my data containers aka records and classes, so I could probably flag this exceptional state before it could poison my function (I dunno if this makes sense lol).
brave walrus
one of the better examples is file handling, lots can go wrong thre
And for throwing, that would depend on what exeption it is. U can make custom exeptions that u can throw all the way to the frontend to indicate a problem
Like user not found in a database. U can make a exeption for that, and in the frontend have a general popup controller that reacts to the ( from backend ) thrown exeption , and shows the error
or the user entering a wrong value -> illegalArgument
_
Deciding on when to throw exeptions usually comes when our doing the anlysis of the code, on what should do what, and how they will be handled.
_
Also 1 more thing. U defo want a throw exeption on your main when your showcasing code, so that it never fatals on unexected things 😉
@ocean zinc , u got 2 replies 😉
ocean zinc
thank you for amazing responses, @brave walrus so it's like giving someone on the other end a way to react to situation? from a beginner's perspective so far it's like using if/else to cover the different scenarios and what to do when that happens?
ocean zinc
Well, I don't have a proper answer to your question, but I'll share my opinion a...
i had initial same thought in my mind, like i can react to these states with something else as well so why exceptions? maybe it's more standardized way to tell fellow programmer "hey, if this happens it means this take care of that" instead of returning -1 which could mean a 1000 different things unless i tell him specifically but then again i'd have to tell every programmer i work with that "hey -1 means this thing" but i suppose with exceptions everyone understand "this means something unsual happened and i may or may not need to react to that in my code"
brave walrus
they can be considerd like if/else, but more like for fatal errors. The person who explained it to me said: things WILL go wrong at one point. Maker your code say this. Shit has happend, please deal with it, instead of a desktop screen
and i said it higher, one of the biggest problems is with file handling, that can go wrong in soo many uncontrolable ways
its up to the programmer or designer what/where such problems will be handled, even if it means telling the user he messed up good
In one of the machines i work with at my job, a German has programd " now call the machine supplier ; do not press any button or press start "
remote shell
Ig it needs to be diff in rust then, but traditional clean architecture argues to never return null. Throwing a custom exception gives much more descriptive nature to the rest of the program other than "something went wrong", u know where it went wrong
https://www.code4it.dev/cleancodetips/exceptions-instead-of-null heres a brief summary that reads pretty well, its C# but reasons the same
forest pumice
a lot of the times the amount of things that can go wrong is too big to describe them by some form of composite state
distant nest
You remind me about myself when I was struggling with exceptions and being confused between checked and unchecked ones. Well today I become aware of the importance of exceptions in software development.
Simply, a program can fail for just about any reason:
-
trying to connect to something remote like a server but no response or the internet is down.
-
You make a mistake in code, for example in a method you have an array of 10 elements, and the code tries to select the 12th element which cannot exist.
👉 Exceptions are 2 sorts some are out of our control, some others can be handled.
For example we cannot restart the down remote server. Instead we can deal with it, which means we inform our system about this situation to not continue waiting a response for more than a certain amount of time.
At the end, exception in java is like saying " I don't know what to do! I give up, please help me to deal with this!".
unkempt sinewBOT
ocean zinc
it's starting to make much more sense now, sorry for the late reply 😅, thank you all for your responses from now onwards i'd try to use them more often to handle exceptions like that instead of throwing if/else blocks haha
ocean zinc
https://www.code4it.dev/cleancodetips/exceptions-instead-of-null heres a brief s...
i have been using if/else like this guy explained lol, btw they mention exceptions are only to be used when there's nothing you can do, what does that mean ? like things that are not in our control?
forest pumice
use exceptions to handle any situations that are not supposed to occur during a program's standard operation
like, don't use them for actual program logic
but for everything else error-related - easily
ocean zinc
here's me, only used exceptions for input
if im not mistaken you are more focused on competitive programming, which is way too different than how developers code. Because for CP getting that fastest solution is the only priority.
ocean zinc
use exceptions to handle any situations that are not supposed to occur during a ...
how do you keep track of everything that could possibly go wrong tho? is there a guide of some sort?
forest pumice
typically an API that you use declares which exceptions it can throw
JDK documents it all over the place, for example
ocean zinc
typically an API that you use declares which exceptions it can throw
but that's what the one who coded is wrote them or handled them, im wondering how do you come up with "what could go wrong", trying to open a file makes sense to me that it might not be present so i shouldnt just assume that it's gonna be there but apart from that iim not sure if i can come up on my own
ocean zinc
oh yes the one uses them handles it right
forest pumice
that's why it is mentioned in the doc, so that the API users know what can go wrong and potentially recover from it
or, they can let it crash but also wrap it in their own exception
which will provide a more useful description of what the app was doing
when you read the stack trace, you can see those "caused by" lines
ocean zinc
yes
ocean zinc
yea i used to think that's random stuff java throws at you, now it makes much more sense to see the stack trace and find the error.
forest pumice
yeah
stack traces are no magic
they're just a list of method calls, from the very root of the thread (like the main method), to the method that threw an exception
ocean zinc
For my use case, i have this db of a student so there's scenario where student does not exist so chef suggested me to throw an exception for that, i was wondering could there be more such cases? for ex what if a student already exists and someoen tries to create an account (suppose i should create one for that too?)
forest pumice
you can write your own exception classes
and subclass them
this way, users of an API can only catch a single exception type
and then, if they wish, check for its subtype
remote shell
For my use case, i have this db of a student so there's scenario where student ...
AccountDoesNotExistException
AccountAlreadyExistsException
e.g.
forest pumice
ofc, you need to also provide methods to check if an account exists in advance
but, like with checking if a file exists, such check is immediately outdated, it's not a guarantee
this is why you can throw an exception
remote shell
A login func might throw the accountDNE and IncorrectPasswordException
While signup throws AccountAlreadyExists or InvalidPasswordFormatException (emg. Not at least 8 chars with a special char)
ocean zinc
yea i plan to throw them via addStudent method
unreal estuary
if im not mistaken you are more focused on competitive programming, which is way...
Yeah 😅 umm...
unkempt sinewBOT