Bloody posted:

i thought i knew the difference between checked and unchecked exceptions but then i read this thread and now i am an even more terrible programmer what is this nonsense all about please explain like i am a terrible programmer

tef posted:

oh I forgot shaggar wants checked exceptions and not option types because he's anti union

quote:

any protips for a fledgling cowboy programmer who needs to make tools other people may have to maintain and use. im still way ahead of most college grads in that i Give A gently caress and dont care what tool it takes to get the job done right, i dunno, yospos help?

Armourking posted:

Armourking posted:

polpotpi posted:

hi cam how is your imac doing?

tef posted:

i also found this neat quine in python

quine = 'quine = %r\r\nprint quine %% quine'
print quine % quine

tef posted:

oh I forgot shaggar wants checked exceptions and not option types because he's anti union

THC posted:

In the Stanford course on iTunes U, the guy says to enable a breakpoint for all exceptions and to just have that on all the time. Is there any situation where I would not want to do this? Most of the projects I've looked at don't have this turned on.

edit: talkin bout Xcode

Cold on a Cob posted:

um no wtf don't use exceptions for normal control flow, test for potential conditions that will cause exceptions and handle them in advance whenever possible

Cold on a Cob posted:

exceptions are a form of non-local goto and should only be used when you have a condition where halting your program and handling it is the only alternative to crashing

they are expensive as gently caress to throw in a lot of languages too

caveat: i'm a .net programmer primarily, i understand python does weird poo poo like using exceptions for control-flow

THC posted:

It is literally a "break whenever an exception is thrown" breakpoint so if you have an exception somewhere thats crashing your program you can turn this on and it shows you the exact line of code instead of crashing and throwing up gobbledygook. The stanford prof recommends to have it on all the time. You can always disable it if it gets in the way of your regular testing but it seems like a lot of devs don't even know this is a feature.

Cold on a Cob posted:

less terrible coders than me talk about it here:

http://c2.com/cgi/wiki?DontUseExceptionsForFlowControl

quote:

I HaveThisPattern, I always use return statements to jump out of nested work, it's a natural pattern when using LotsOfShortMethods, goes right along with GuardClauses to bail early.

PleasingFungus posted:

it's entirely possible for one section of code to be unable to handle an error condition (e.g. "missing file"), which a higher-level section of code can handle & recover from

this is in fact a canonical use of exceptions

and my point was that you probably don't want to fire a breakpoint every time that happens

Cold on a Cob posted:

python sucks sorry

Cold on a Cob posted:

the higher order code should check for the file in advance and handle it then if its something that will happen often (ie normal code flow)

exceptions are reserved for unexpected error conditions

If it doesn't happen often then it won't hurt to have break on exception turned on and it will help you realize you have a problem if it starts happening suddenly even if your code is robust and recovers

ur wrong on this sorry

Cold on a Cob posted:

exceptions are reserved for unexpected error conditions

PleasingFungus posted:

now the file (or whatever) isn't there. A doesn't have the information necessary to recover from a missing file; it throws an error. B catches the error & sets up a default configuration of some kind.

PleasingFungus posted:

tbqh I don't really understand how you can reconcile


with the idea of "catching exceptions".

where exactly do you use exceptions? when do you catch them, if you're only supposed to use exceptions for situations you don't expect? I'm honestly really curious here.

Brain Candy posted:

its you, you are the coding horror. you check if the file exists in B. an exception is thrown if somebody somehow deletes the file from under you or fills it with spiders.

JewKiller 3000 posted:

modern programming languages (not java, definitely not any p-lang) make it trivial to declare the return type of a function as an option type, i.e. "ok here's the value OR error", and furthermore the ok/error tag MUST be checked before the potential return value can be extracted

Cold on a Cob posted:

you use them for catching and handling exceptions that are a possibility but do your best to ensure they are never caught in the first place by guarding for them wherever possible

if it is a common scenario in your application that files may not be present or may not validate in some manner, you should be testing for that in the normal flow of your program and dealing with it within the normal flow of your program because it is expected. if that means more thorough testing in each function and passing poo poo back up the stack, so be it.

if it is an uncommon scenario in your application that files may not be present, then by all means use an exception, but treat it like the catastrophic event that it is. catch it and deal with it (eg stop program flow, log the error, have it send an expletive filled sms to your webserver cj's wife)

in c# a good example is using int.TryParse vs int.Parse - you use TryParse when you expect conversion to fail and you use Parse when you never expect it to fail and if it does you want an exception generated.

now, to be fair, i am arguing from authority (essentially, everyone knows non-local goto is bad and should be avoided ). i'm not going to get into all the reasons why non-locally scoped gotos are a bad idea, but if you want to argue that you like being able to shortcut your way up the stack in a non-obvious way when something you expect to happen 5% of the time happens and you don't mind incurring the performance hit for doing so, not to mention making your code less obvious in it's expected operation, have at it but i pity anyone that works on your code base 5 years from now.

Cold on a Cob posted:

heyyyyy look at me i'm arguing on the internet about programming on friday night

PleasingFungus posted:

that's nice for people who get to use fun languages over in academia

for people who work in the real world, we have to deal with actual languages

good to know though!

PleasingFungus posted:

hm. I guess the question is something like this:

you have a function. when called, it's unable to return a meaningful result. (a function that's supposed to read from a file doesn't find a file; a function that's supposed to parse formatted data is passed garbage.) what should the function do?

in my philosophy, the function should throw an exception, and that exception should pass upwards until it reaches a function that's capable of dealing with it. ("C" in my earlier example.) I don't think this is particularly controversial, tbqh.

your argument seems to be that exceptions should be used as more verbose quit() calls with nicer error-logging functionality, and only as that. in your scenario, our functions would return error codes instead of actual data in these cases, and every upstream caller would have to pass that on until they reached a function that could deal with the error. that's literally what exceptions were invented to get away from, because it turns control flow into a hideous nightmare, and you don't have any actual argument for returning to it (besides "authority"), so... I guess I'm not convinced!