p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

Max Facetime: Apr 18, 2009

instead of using option types and sprinkling error recovery code all over the place, why not use a singleton varying type to centralize error handling and correction into just one place?

# ? Aug 30, 2013 06:35

Adbot: ADBOT LOVES YOU

# ? Jun 3, 2024 20:24

hepatizon: Oct 27, 2010

tef posted:

in ruby parlance, a dsl is what they call libraries.

excel.

my job involves non-programmers writing highly abstract ruby in spreadsheets :getin:

# ? Aug 30, 2013 06:56

Notorious b.s.d.: Jan 25, 2003; by Reene

Max Facetime posted:

instead of using option types and sprinkling error recovery code all over the place, why not use a singleton varying type to centralize error handling and correction into just one place?

wouldn't this just be exceptions again

# ? Aug 30, 2013 07:02

Zlodo: Nov 25, 2006

the main rationale behind "exceptions should be used only for truly exceptional cases" is pretty simple: exception handling is slow.

I dunno how they are implemented in java but in c++ the way they work on a decent compiler (ie not vc++) is that when the exception is thrown a bunch of lookup tables are used to unwind the call stack and find out which objects need to be destructed until a suitable handler is found to catch the exception.

(vc++ just pushes and pop exception handlers on the stack during the normal execution flow so it slows you down even when you don't throw. Good job by microsoft as always)

so basically if you are at least slightly concerned about performance you shouldn't use exceptions for things that are expected to happen during a normal execution of your program

for instance imagine you can load config files or plugins from multiple location, like you try the current dir first, then a user specific location, then a system location. you try loading your thing from all these places and a lot of failures are expected. if you use exceptions for that you'll have a bunch of them thrown every time although nothing bad is actually happening that justifies using such a costly mechanism

# ? Aug 30, 2013 09:06

unixbeard: Dec 29, 2004

Flaming June posted:

i'm not interested in writing an os or anything like that. i've just been a windows user for most of my life and now am in the, erm, wonderful world of unix. it isn't so much that i want to just learn a lot about unix, but the experience open ups a horizon that there are many ways to do even simple stuff in the background. i find it to be kind of cool in a nerdy way

This is the best book if you want to learn about how unix works http://www.amazon.com/Programming-Environment-Addison-Wesley-Professional-Computing/dp/0321525949 ignore the advanced part though, it gets into details for sure, but starts off pretty introductory

# ? Aug 30, 2013 09:52

Condiv: May 7, 2008; Sorry to undo the effort of paying a domestic abuser $10 to own this poster, but I am going to lose my dang mind if I keep seeing multiple posters who appear to be Baloogan.

With love,
a mod

Zlodo posted:

the main rationale behind "exceptions should be used only for truly exceptional cases" is pretty simple: exception handling is slow.

I dunno how they are implemented in java but in c++ the way they work on a decent compiler (ie not vc++) is that when the exception is thrown a bunch of lookup tables are used to unwind the call stack and find out which objects need to be destructed until a suitable handler is found to catch the exception.

(vc++ just pushes and pop exception handlers on the stack during the normal execution flow so it slows you down even when you don't throw. Good job by microsoft as always)

so basically if you are at least slightly concerned about performance you shouldn't use exceptions for things that are expected to happen during a normal execution of your program

for instance imagine you can load config files or plugins from multiple location, like you try the current dir first, then a user specific location, then a system location. you try loading your thing from all these places and a lot of failures are expected. if you use exceptions for that you'll have a bunch of them thrown every time although nothing bad is actually happening that justifies using such a costly mechanism

I recently read exception handling is drat slow in java too. Pretty much if you have an error you can recover from, return it with an Either or something from your function or your code will perform like crap.

Condiv fucked around with this message at 09:57 on Aug 30, 2013

# ? Aug 30, 2013 09:53

unixbeard: Dec 29, 2004

the cost of exceptions

is too drat high!!!

lol

# ? Aug 30, 2013 09:57

Deus Rex: Mar 5, 2005

at my old PHP job I shaved like 300 ms off the average response time for a bunch of web API endpoints. how? an API endpoint specified its parameters with something like:

PHP code:

$id = Param::required(Param::Id, "id");
$butt_name = Param::optional(Param::String, "butt_name");
$butt_size = Param::optional(Param::Int, "butt_size");
/* etc... */

the implementation of Param::optional was something like:

PHP code:

class Param {
  private static function get($arr, $type, $name) {
    if (array_key_exists($name, $arr)) {
      /* do some poo poo to coerce $val into the type idk */
      $val = $arr[$name];
      return $arr[$name];
    } else {
      throw new ApiExceptions\MissingParam();
    }
  }

  public static function optional($type, $name) {
    try {
      return get($_GET, $type, $name);
    } catch (Exception $e) {
      return NULL;
    }
  }
}

you might wonder why a couple optional parameter lookups (and consequent exception throws/catches) per request added 300ms to the response time. as it turned out, the omakase DB conn/query object written by our senior developers had like 50 debug statements to dump information about the conn/query/whatever.

PHP code:

class Mysql {
  private function _somethingCalledSometimesHundredsOfTimesPerEndpoint() {
    /* ... */
    Debug::dump("mysql and php are omakase");
  }
}

and the loving impl of Debug::dump, loving of course:

PHP code:

class Debug {
  public static function dump($str) {
    $debugMode = Param::optional(Param::bool, "debug");
    if ($debugMode && self::someOtherStuff()) {
      self::logThatShit($str);
    }
  }
}

so that's how i learned that php also has agonizingly slow exceptions! (and also that the senior developers had never not once profiled anything)

Deus Rex fucked around with this message at 10:27 on Aug 30, 2013

# ? Aug 30, 2013 10:24

unixbeard: Dec 29, 2004

cool web development story

# ? Aug 30, 2013 11:21

a nest of hornets: Nov 17, 2012; by Ralp

unixbeard posted:

the cost of exceptions

is too drat high!!!

lol

# ? Aug 30, 2013 11:57

prefect: Sep 11, 2001; No one, Woodhouse.
No one.; Dead Man’s Band

Zlodo posted:

for instance imagine you can load config files or plugins from multiple location, like you try the current dir first, then a user specific location, then a system location. you try loading your thing from all these places and a lot of failures are expected. if you use exceptions for that you'll have a bunch of them thrown every time although nothing bad is actually happening that justifies using such a costly mechanism

in this case, would The Right Thing be to throw an exception only when there are zero config files?

unixbeard posted:

cool web development story

i thought so, too

# ? Aug 30, 2013 12:25

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

prefect posted:

in this case, would The Right Thing be to throw an exception only when there are zero config files?

depends on context. like, are they config files the program put there itself on install? if the user has gone into the program directory and deleted them, i'd consider that exceptional behaviour.

if they're config files that won't be there if the user forgot to install some dependency, that's the kind of thing you should see coming.

# ? Aug 30, 2013 12:37

Shaggar: Apr 26, 2006

You test for the existence and read/write-ability of the file before read/writing it, but sometimes things happen after that check so you'll have to handle a potential i/o exception.

In the case of loading configs from multiple places you'd be fine to ignore non-existence until you get to the last location assuming the config is required to run the program.

# ? Aug 30, 2013 12:47

prefect: Sep 11, 2001; No one, Woodhouse.
No one.; Dead Man’s Band

what if one of the files turns out to be all mangled with binary non-text data in it? do you blow up there, or do you keep moving down the config-file tree?

# ? Aug 30, 2013 12:50

Shaggar: Apr 26, 2006

You'd have to decide how you want to deal with it. Generally if a user config is corrupt you probably want to make it known you couldn't load it cause they're expecting it to be used either thru ui if you have one or by logging and exiting. Otherwise they're gonna assume its running with their config when its actually running with another and that could cause problems.

That won't always be the case of course so figure it out during your design phase.

# ? Aug 30, 2013 12:56

Shaggar: Apr 26, 2006

I it has a ui you should help them recreate the config right there instead of exiting.

# ? Aug 30, 2013 12:58

prefect: Sep 11, 2001; No one, Woodhouse.
No one.; Dead Man’s Band

Shaggar posted:

You'd have to decide how you want to deal with it. Generally if a user config is corrupt you probably want to make it known you couldn't load it cause they're expecting it to be used either thru ui if you have one or by logging and exiting. Otherwise they're gonna assume its running with their config when its actually running with another and that could cause problems.

That won't always be the case of course so figure it out during your design phase.

what's your opinion on machine.config files? (i kinda want to murder them, but maybe i had bad experiences)

# ? Aug 30, 2013 12:58

Shaggar: Apr 26, 2006

I had not heard of it before now. Anything that would go there would probably be fine in a shared system config in like program data or w/e. I wouldn't want to share a config file with other apps cause someone's gonna think they're special and not use the API to edit it and break it. The registry would be also be a better spot since there's no non-API access and it does the same thing.

Lastly you could also load configs from a central source based on application and machine id.

# ? Aug 30, 2013 13:06

prefect: Sep 11, 2001; No one, Woodhouse.
No one.; Dead Man’s Band

Shaggar posted:

I had not heard of it before now. Anything that would go there would probably be fine in a shared system config in like program data or w/e. I wouldn't want to share a config file with other apps cause someone's gonna think they're special and not use the API to edit it and break it. The registry would be also be a better spot since there's no non-API access and it does the same thing.

Lastly you could also load configs from a central source based on application and machine id.

well, in this situation, the stuff we put in machine.config was mostly connection-string data so the systems knew where the central source was

# ? Aug 30, 2013 13:09

Brain Candy: May 18, 2006

also, the other things about exceptions being too slow

1) You don't care
2) You care because the profiler said so
3) If the profiler said so, a ton of bad things are probably happening in your code
4) and they're in the structure of your program

"x is slow" is usually given without context to make it useful, and I'm not a fan, no sir.

# ? Aug 30, 2013 13:25

MononcQc: May 29, 2007

use a language with proper exception support :smug:

if your exceptions are so slow people fear to use them for what they were semantically meant for, they're poo poo :smuggo:

# ? Aug 30, 2013 13:26

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

MononcQc posted:

use a language with proper exception support

if your exceptions are so slow people fear to use them for what they were semantically meant for, they're poo poo

well what they're semantically meant for is the bone of contention, isn't it? and really i think that argument comes largely from whether you prefer the devil of having the normal "happy path" control flow of a program obscured by error handling details, or the devil of having a non-local return obscure what the hell happens when something goes wrong.

# ? Aug 30, 2013 13:56

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

ps czech out what one of the lil babbys at my alma mater is doin http://rcos.rpi.edu/project/smith-language/post/project-proposal-smith-language/ apparently its his third shot at doing a compiler. on the mailing list for the funding entity there have been good discussions, i teased out of him that internally it's a forth as i suspected as opposed to a paren-less lisp :3:

# ? Aug 30, 2013 13:57

tef: May 30, 2004; -> some l-system crap ->

Otto Skorzeny posted:

well what they're semantically meant for is the bone of contention, isn't it? and really i think that argument comes largely from whether you prefer the devil of having the normal "happy path" control flow of a program obscured by error handling details, or the devil of having a non-local return obscure what the hell happens when something goes wrong.

don't you understand, exceptions are for whatever purpose I was told to use them for

# ? Aug 30, 2013 14:06

tef: May 30, 2004; -> some l-system crap ->

a quick survey, who has read the paper on exceptions ?

quote:

In short, exceptions and exception handling mechanisms are not needed just to deal with errors. They are needed, in general, as a means of conveniently interleaving actions belonging to different levels of abstraction [2-7]. They are not necessarily rarely activated. For example, in their use in dealing with result classification, they might be activated on every invocation of an opera- tion. In their use in monitoring operations and receiving intermediate results, an exception might occur many times for a single invocation of the operation. Exception handling notations that imply a fixed implementation technique are therefore not suited for dealing with the complete range of exception requirements.

christ, programmers

# ? Aug 30, 2013 14:10

Jonny 290: May 5, 2005; [ASK] me about OS/2 Warp

now i just might be an ignorant perl coder but isnt it a bad idea to use exceptions for non-error control flow?

# ? Aug 30, 2013 14:11

tef: May 30, 2004; -> some l-system crap ->

quote:

eh, exceptions in modern languages are overloaded language features, doing a number of things:

- non local exits
- error handling (both of the recoverable and unrecoverable types)
- semipredicate problem (cf "0 but true", option types, python's generator protocol)

(aside: exceptions are overloaded much in the same way java decided to mash subclassing and code-reuse together, rather than say having separate features for each like traits and mixins.)

if you read higher order perl (or you know what "0 but true" is for in Perl), you'd know what the semipredicate problem is and how exceptions can be used

# ? Aug 30, 2013 14:16