So how long have been try/catching api calls then?

I don't think speed is a huge issue in regards to exception handling - 1000X sounds like a contrived situation where one is unwinding the stack in an expensive way and - but in a context where you're manually managing resources (usually memory but could be other things), exceptions are often problematic and it's probably impossible to provide safety without banning exceptions from at least certain types of code. I would probably try to minimize the use of exceptions if I need to provide extremely highly levels of reliability in C++ for instance or even a Java/C# if I'm doing a lot of low-level stuff.

I know checked exceptions are universally reviled now but it sort of made sense at the time if you assumed most people care about reliability and semantics and stuff at this level (which they don't). It's really hard to write reliable code if you don't know what can throw exceptions and what can't. But as it turns out, most of what we write is low-quality, brittle stuff with so many bugs that relies on "error-handling" at the application/service level (have you restarted your computer^H^H^H^H^H^H^H^Happlication/service) so strict guarantees are just not that useful anymore.

I think that Wolfram is saying that client side validation is 1000x faster than server side. Network transit time makes this a given.

Speed of exception handling vs other means will vary from language to language. For example, I know that in Rails/Ruby the equivalent of try catch is substantially slower than most other ways of catching problems. And even a rails method foo.try(:method) that is meant to protect against calling methods on a null object is substantially slower than foo && foo.method. not 1000x slower but a large enough percentage to care about in any code that is run frequently or in a tight loop

to be fair, I was talking about exceptions being slower and pulled the 1000 number kinda out of my ass. I think I saw it in a stack overflow answer somewhere.

I'd be surprised if the speed part makes a big difference. The bigger issue to me is if throwing errors makes sense semantically for validation problems.

I'm in the camp that error flow should be for true errors. I'm not a big fan of normal-flow caught exceptions - because inevitably you want to do things other than just bubble up the exception and return something to the client. Either bubble all the way up, or no bubbling. Forked bubbling is a rabbit hole imo.

You could make a much better case for try/catch server-side validation errors if you also have mirroring client-side validation. That way a server-side error should be extremely rare. Although I guess if there is a perf issue that opens you up for DDOS.

I knew you pulled it of your ass. Did a little research on this today. I hopefully will be motivated to do a post in depth on this topic. At this point, let me state that technological advancement is a lot about addressing issues/weaknesses. What may have been an issue a decade ago is often rectified today in my view.

In the work I do, I can't use exception handling due to memory resources it requires.

try/except vs if/else isn't all that big a deal, at least in python, just be consistent. altho there's a mantra of better to ask forgiveness etc etc

more troubling is you have to write this boilerplate yourself, are you hand rolling your own REST API

if so, i wouldn't c/p the code and would add an abstraction layer (say at serialization) to validate user data (i hope to dear god your ORM isn't hand-made and handles malicious stuff)

checkout DRF for some patterns:

http://www.django-rest-framework.org/

adios wtf are you doing that's memory-bound at the API layer?

I hate Django Rest Framework with a passion. I don't like ORMs in general. Anything more than a very light framework has always seemed like a pretty bad idea to me.

+1

<3 mongoose imo.

for fun I've decided I'm going to reply to every single recruiter email outside of the hugely obviously spam (out of state non remote jobs) with the following text:

"$?"

and will follow up in a week or two with results. I'm thinking:

40% no reply
55% "its really DOE, what are you making now" stuff
5% an actual range/a real response

we'll see!

If they don't respond with "0" are you going to bin their responses?

I'm binning 99.99% of their responses.

Just changed your linkedin to architect. Recruiters will leave you alone.

How are you folks getting so many LinkedIn messages? I get only maybe once per month.

But I guess that's also because I only have been at my company for 6 months.

Agree with all this. I'm more talking about situations where the API takes an input that is supposed to be an integer, say, and force-casts it from a string to an integer, throwing an exception that is then caught by a try-catch block which surrounds the whole method as a catchall. Maybe that's not what Craggoo is talking about but that sort of thing is pretty common. The speed issue is one reason it's bad but the main ones are:

- Specificity: If the force-cast throws an exception I may just want to return an error to the client and not log it, since that's expected behavior, whereas the same exception thrown elsewhere in the method may reflect a serious error that should be logged. As the method is maintained and other code is added to it, the risk that new code will add exceptions that will be silently mishandled increases.

- Explicitness/Maintainability: I can't easily tell from reading the code what will happen if the cast fails. I have to go dig into the exception handler and be knowledgeable enough about the language to know what the exception types are in various failure cases before I can tell what will happen. Obviously the really bad scenario here is that the exception is allowed to bubble up and is handled off in some random place in the code.

I've been at my company for 3 months and I get a recruiter message every other day.

All my profile says for this job is react/redux/es6

I also have like 3k connections tho so I assume I smash the search results by being a 2nd or 3rd connection to the recruiters.

Try updating your profile. That seems to trigger new messages as recruiters think you might be looking.

What ChrisV said regarding validation exceptions.

I haven't worked for the man a day in my life so I basically know nothing, sorry for stupid question.
I've taught myself some programming, did some courses and long story short have an interview for a full-time junior developer position coming up soon.

I wonder what my expectations should be re: chances to get hired.

I already did a telephone "interview" with them that went great (they hired someone who completed the same course as me before but I also made a project on my own that positively blows everything we've learned out of the water, no reason for false modesty here, I have, like, actual paying users).

After that I sent a written application and they asked me to come by (pretty casually actually).

The position is in another city where I'd move to, they already said they can possibly help with getting an apartment.

To me this all sounds pretty great, I mean I wouldn't ask me to come there if I were in their shoes and not particularly interested. I'm also kind of a smooth talker so I think the interview will rather go well than bad but who knows.

Anyway, what % of the time should I expect to get an offer? Never did anything like this before haha.

I'd say your chances pretty good if you got the second interview. Just don't pretend to know anything you don't. They'll be hiring you for your gumption and ability to learn. It's basically how I got my first few programming jobs.

Ya I'm planning on being honest: I'm certain I can learn anything anyone ever would reasonably throw at a junior developer but I will most likely have to learn it on the job, first.

Btw love reading your posts in general, one could say you've unknowingly been an inspiration to me haha!

I mean given what you have said you sound like a slam dunk hire.

I would imagine their only major thoughts will be with culture fit.

I am pretty sure that all junior developers learn pretty much everything while on the job.

but ya, I would say you should play up your ability to learn and to learn quickly.

and I agree that suzzer is an inspiration. one day I too hope to be able to pull of a multiple simultaneous remote jobs. truly heroic.

It's definitely not a slam dunk. Lots of places bring promising candidates in but expect a non-trivial fail rate. I don't know what ours is, but its significant. Getting an in-person interview after phone + assignment is definitely not a slam dunk.

There's cultural fit, but there's also just the fact that interviewing is hard and a lot of people (everybody?) are bad it. So its totally possible they're going to ask a question you don't know the answer to that they think is important and so they fail you.

I'm not saying this to discourage anybody, but its the reality. And its also important to know that failing interviews doesn't necessarily mean you're a bad candidate.