try {
…..
} catch {
// this would never happen
}

and then it happened

fucking always print something when you catch exceptions

@rEaL-jAsE > "Why aren't you handling these exceptions?"

Cause at his EOY review, they say "Wow vane, your code never crashes and never logs any problems...well done. You get everyone's bonus's this year."

@rEaL-jAsE

Often the only good reaction is to log and die with an error message.

the best version I found in our code was

try {
SomeLogic();
catch(...) {
throw;
}

*growls*

it:s sad and enragening that you have to explain the basic of basics, logging, to people...

Especially to explain context based logging. Most don't even know what this is...

Which is a constant pain in the arse.

@IntrusionCM > "sad and enraging that you have to explain the basic of basics, logging, to people"

and/or you see the most obtuse rube-goldberg machines built to log a 'I am here' string.

@PaperTrail

logger::info "started XY"

Statements like this... Or yours... Even more anger.

Log after something has happened. It's irrelevant that sth has been started - it's relevant when it's either failed or was successful.

@aaronswartz i hope you just now graduated ;)

@aaronswartz

Damn snobby pure functional evangelist...

Or are you just only doing embedded or kernel stuff?

@soull00t hopefully you’ve got an IDE that will yell at you for re-throwing exceptions.

@Oktokolo disagree on the dying. Aborting probably but dying is reserved for when the core task cannot be proceeded anymore.
When you die if one REST request cannot be handled in flight requests are also failing. If the program failed to initialise or is a sequential script dying is likely the best option.

@AvgCakeSlice yeah sure, I mean.. the IDE we use is absolutely capable of doing something like that.... ツ

@hjk101

For a REST service, dying means: Send some error code and message, then terminate the worker (if local state could be tainted) or continue with next request (if workers are stateless).

For a user-faced page, it means rendering a generic error page.

For a server-based widget on a user-faced page it can also just mean to omit the widget or display an error instead of the widget.

The point is to not contiue using a potentially invalid state to avoid executing a weird machine.

@Oktokolo Ah that is a very specific (and different than I'm used to) definition of die. I thought more along the lines of program termination like Perl's die.

With your definition it makes sense, though any state tainting between requests is a bug IMO.

@hjk101 I thought that too, though one must really be brain damaged to call exit in a rest point and shooting down the server.

So yes, the longer version is more correct, but I guess it was kinda obvious what he meant. XD

By the way - Elasticsearch had in it's Rest API till 2.0 I think a shutdown API endpoint for a node....

I should stop thinking about all the wrongs I've seen in the world....

@hjk101

Yeah sorry. Wasn't really specific in that oneliner.

But i would also call a function pure even though it calls a logger or increases a statistics counter - as long as these actions aren't actually a part of the reason for the function to exist...