Re^18: eval to replace die?

[mithaldu]

in reply to Re^17: eval to replace die?
in thread eval to replace die?

Just a simple real life example, derived from my day to day work:

An application that deals with item prices delivered by third party servers (so, unknown ahead of time) and does a change check before each action that has to do with actual cash. If the price changes, it backs out and tells the user, with the message highlighted in red or green. Prices are displayed in full euro values at all times for brevity.

With exceptions:
die { type => 'PriceChange', amount => -123 };
The exception handler can recognize it by eq'ing the type and derive the direction from doing a numerical inspection of the amount and then shunt the whole thing through a template generator.

With strings:
die "PriceChange: The price changed by -123 Euro.";
The exception handler does:

$error =~ m/^(\w+)\:.* ([-\d]+) /;
if ( $1 eq 'PriceChange' ) {
    my $direction = determine_direction( $2 );
    return price_change_error( $error, $direction );
}
else {
    return "UNKNOWN ERROR!";
}

Both work fine. Now management decides: "We want the decimals displayed!"

So the die errors get changed:

die { type => 'PriceChange', amount => -123.45 };
die "PriceChange: The price changed by -123.45 Euro.";


You see what happens, right? And just in case you try to argue "this code is dumb", yes it is. But let me assure you it's tame against the shit i've seen in production over the years.


And lastly, i'm not going to try and address your wall of text at the bottom there. I dislike Java as well, i dislike OO as well and only use it when i can't think of a lispy way to do something. But i never labeled you as an OO-hater, you made that up on your own. I merely said that i think you're too busy hating Java to allow yourself to see that E::C has little to do with it at the core.

[BrowserUk]

You see what happens, right?

Yes. You've made a change to the program, so you run it through your test suite. ( You do have one don't you?)

You discover the problem and you correct it. End of.

But let me assure you it's tame against the shit I've seen in production over the years.

Then fix your process.

[mithaldu]

With an exception that is a structure there is no need to correct any problem. The test suite still passes because there is no problem.

Which was the whole point of this entire debate: It is much easier to run into trouble by using string-only errors.

[BrowserUk]

It is much easier to run into trouble

Coding a feature change is not "running into trouble". Doing a half-assed job of it is just sloppy. Allowing that sloppiness to get into production is bad process. You cannot correct bad process by over-engineering.

Your derived contrived example code made no sense.

There was no reason to parse the error message. You never did anything with the results of the parsing.

Which was the whole point of this entire debate:

You think? Read again.