Re^14: eval to replace die?

[mithaldu]

Alright, i'll give it one more try to see if i can get through to you. Here's how the situation looks like to me:

<chromatic> errors like "Error:ID:001|description|extradata:eins,zwei,drei" are terrible, because if you parse them with regexes, shit is hilariously easy to break in ways that are hell to debug or worse, you won't even NOTICE
<BrowserUK> but with exception objects you still have to compare strings, SO THERE!

You completely miss the crucial difference between a simple string comparison and a regex to deparse something. The former is fine because that's what perl even does when calling builtins, because they are ALSO in a hash table. The latter is a nightmare when you're dealing with inputs that are bound to change.

That was exhibit one. But there is more to come.

Um...apart from that it wasn't available until 5:30am today
The module synopsies use: ... Which to the best of my abilities, simply doesn't work!

My example is a cut-down version of the synopsis, with some things changed to make it more readable for perl developers who are really adverse to thinking about things. Furthermore, the synopsis works. You can dump it into a .pl file, add a hashbang at the top and execute that and it will just plain work.

Have you even tried that or did you let your prejudices guide you?

essentially throws away the purpose of half the code including two of the dependencies of E::C.

E::C's code consists of two files:
Class.pm - a factory for exceptions
Class/Base.pm - a base class with all the things exceptions can do

Its depencencies are:
Class::Data::Inheritable = 0.02
Devel::StackTrace = 1.20
Scalar::Util = 0
perl = 5.008001

So, seriously, what the hell are you talking about? Neither of this has an overlap with Try::Tiny.

There should *never* be an occasion when the failing routine has to pass you information to deal with an exception that you don't already have access to. After all, you called the routine and passed it the relevant information!

You have never worked in a team where components are written by different people.

eval & die is a legitimate other way; that has been acceptable to Perl programmers for the best part of 20 years; and is used, where needed, by 18,000+ (-60 that use E::C) CPAN modules.

Do you think Justin Bieber is an amazing artist and provides rich value to the human culture? (Hint: Appeal to popularity is a fallacy.)

But does no one see how easy and lightweight that can be done: die %hash

Yes, i did that for a while. It's nicer than strings, for reasons explained at the top, but it's also a bit clunky and makes you type a lot of stuff. I ended up having to boilerplate a lot when throwing exceptions like that, so having a module that provides a bunch of that kind of stuff in one is neat.

Now, one point i have to concede: The API for E::C is a bit atrocious, and forces you to also do a lot of boilerplating. Thus: http://www.reddit.com/r/perl/comments/domue/rfc_simple_callerbased_exception_creation/

[BrowserUk]

Alright, i'll give it one more try to see if i can get through to you.

There is no need for you to "try to get through" to me. I understand what you (and others) are saying. I just disagree with your conclusions, and I've tried (hard) to present my reasoning in detail. You can either accept or reject my reasoning, but re-stating your flawed position over again will not change my reasoning, nor my conclusions.

You completely miss the crucial difference between a simple string comparison and a regex to deparse something.

No I didn't. But you apparently didn't read half my post, because it you had you have read the bit where I showed that there is no good reason to "deparse" the error string.

"Exhibit one" fully rebutted!

Have you even tried that

Of course I did, but the synopsis code, all in a single file, is not useful. So I tried and posted a realistic example. It doesn't work:

C:\test>exceptions 1 0
Can't locate object method "throw" via package "MyExceptions" at C:\te
+st\exceptions.pl line 8.

I invited corrections, none were forthcoming.

My example is a cut-down version of the synopsis, with some things changed

And the things you changed mean that you're not using half of the functionality of the module. You don't use either of the ->throw() or the ->caught() methods. You use Try::Tiny for this functionality, presumably because you couldn't get them to work either.

BTW: E::C throw() and caught(), and Try::Tiny's use of die and catch{} are overlap!.

(Hint: Appeal to popularity is a fallacy.)

Statements of verifiable fact are not "appeals to popularity"; and by definition, cannot be "fallacy".

Do you think Justin Bieber ...

Who?

---

Further restatements of our respective positions serve no purpose. Let's just accept that you think I'm an idiot; and I think that you are too caught up in trying to suggest that I am, to have bothered to read what I've written and make any real attempt to apply logic to it.

I'm done.

[mithaldu]

re-stating your flawed position over again

"=~ is more volatile than eq/ne" is flawed?




I invited corrections, none were forthcoming.

Yeah, sorry, i admit i didn't bother to read every single thing before my first post because stuff is very wordy. Here's your problem:

use Exception::Class <stuff_here>; does two things: First, it instantiates all the classes you ask for. In this case MyException being one of them. Optionally you can also ask it to export shortcut subs into the module where you use it. In your case you only ask it to export throw_fields.

To fix your example, change the two "MyExceptions" in sub divide to "MyException", so you're actually trying to throw with the class of an exception (by your use of caught, this is presumably the right option).

D:\Exception-Class-OnCaller>perl bluh.pl 1 0
The second argument must not be zero at bluh.pl line 38.




And the things you changed mean that you're not using half of the functionality of the module. ... E::C throw() and caught()

These are merely convenience functions, clocking in at 15 of 415 code lines (without docs). That is 3.6%. The rest and the majority of the code deals exclusively with the creation of exception objects.

The only reason i did not use them is because i personally do not like them and think T::T looks nicer. Your assumption that i could not get them to work is not correct as my fix to your example above proves.

"Ex->throw" is literally just a shortcut for "die $ex || Ex->new". This has nothing to do with T::T's try, since THAT function does much more stable wrapping of code and does nothing to create exception objects, but only stores them if the wrapped code emits them.

"caught" is only there so you can inspect the errors from the eval and compare them to certain targets in one line. It has only superficial resemblance to try's catch, which is aimed at security and stability and does not have the convenience of actually inspecting the exceptions.

The intent of Exception::Class is merely to provide exception objects, not to provide exception handling. These are two very different domains.



Let's just accept that you think I'm an idiot

I don't. At this moment i am of the belief that your hate of another language(*) does not allow you to evaluate things in a complete and rational manner. If i had good memory i would insert a jedi quote here.

(*) And on inspection of your the post with your example, also your hate of one specific person.

[BrowserUk]

"=~ is more volatile than eq/ne" is flawed?

Yes. It takes only a one character typo or transposition to screw either up. And once tested, both are proven until something changes. When something changes, both need to be re-tested. Regex may be harder to get right, but once they are tested as correct, they don't suddenly start randomly acting differently. If they matched today, they will match tomorrow, unless something else changes. And when something else changes, it is just as likely to screw up eq as =~.

That is a complete, dispassionate, rational evaluation. It is also incontrovertible.

i am of the belief that your hate of another language...

The language in question I think has done the industry I've loved being a part of for the last 30 years, a considerable disservice.

Java probably has no more bad programmers as a percentage, than any other language, but because they are a) more numerous than most other languages; and b) the consequent high demand for them, means that forces of natural selection that usually weed out the worst, hasn't operated as it normally would; combined with c) the artificial "legitimacy" that somehow arose around it; means that companies around the world have tried to reduce the art of programming--and programmers--to a commodity items.

Instead of employing a number of higher paid, higher skilled programmers and analysts (and project managers), they started trying to throw large numbers of low-paid, less skilled people at projects. Java enables that because it effectively reduces all language development to a single construct: object.action( args );. This is very easy to teach, and so you can push large numbers of people through certification processes very quickly. But along the way it produced a whole generation of programmers that know only one way to everything. They have no exposure to procedural, funtional or any other style of programming than OO. And that's a monoculture. And monocultures are always bad.

The result is that each individual developer, analyst or architect concentrates upon one tiny part of an overall project with no one person having a full overview. And the bloated, discordant, memory and cpu hungry results of that have become manifest.

I like OO. I use OO (when appropriate). I'm even quite good at OO. So your attempts to label me an "OO hater" cut no ice. I'm just sufficiently experienced to know that there are other ways of doing things; and for many problems they are better.

also your hate of one specific person.

It is a matter of personal ethics that I don't "hate" anyone. Much less people I have never met, nor even had a one-on-one conversation with.

Read my sig. I argue the the issues; never the person. But you cannot argue the issues effectively without talking to their main proponents. Trying to take my arguments against a person's stated position; as any kind of emotional attack on that person, is the last refuge of the desperate.

I love the Perl language. And I take issue with anyone I perceive to be advocating the "dumbing down" and commoditasation of Perl. I do so, because I believe that it is detrimental to Perl in the wider context. But I have nothing to gain from my efforts except, perhaps, whatever long term effects my dispassionately logical arguments might have upon individual members of the Perl community. Or not.