when to throw an exception?? I know what exceptions are, but

>>60858037

when you reach a point where the program literally cannot perform as required due to bad user input

When there is something outside the scope/control of your program that is capable of erroring out and taking your program down with it. I view TCP as an example. You pretty much need exception handling around TCP due to the number of ways it can fuck up that have nothing to do with you.

>>60858086
This is the only acceptable answer

You use exceptions instead of returning booleans when its deemed unlikely for something to go wrong but there is still a possibility of said thing going wrong.

Ex: Ajax requests, accessing shit without permission in android, accessing a memory address without permission inside a vector class in c++. Stuff like that.

At random.

>Select random number from 00001-99999
>if this matches the last five digits of the Unix timecode, throw a cryptic exception
>Select another random number because 00000 and 99999
>This is the number of seconds before you repeat this

>>60858183
What about catchable exceptions? If you catch it, you can recover from it, so why throw one in the first place?

Never throw exceptions

If it's catchable, it's fixable.

>>60858728
>>60858664
If you are making a library, is better to throw the exceptions up to the main program can catch it and deal with them.

Ex: on MVC if your database is down and your model class failed to connect instead of catching the exception, throw it to the controller class and deal with it on the business layer.