I just found out about the Error class :) but I'd like to see it taken one step further; catch should always return an Error (related class) not a mixed.

Error err = catch {...};

That way there's no need to code a lot of specific error analyzing code when receiving an error, to just get the message and stacktrace/backtrace

Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

You mean like this?

Pike v7.7 release 44 running Hilfe v3.5 (Incremental Pike Frontend)

...

catch { throw(Error.Generic("Hello")); };

(1) Result: Error.Generic("Hello")

__________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken.

The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________

Then I would have a problem if I just want to display the error message. Next to that, according to the documentation it only handles Errors and arrays (effectively). I would very much like instant access to just the stacktrace, error message or object attached to the Error.

Using describe_error also limits me to a single error report. (BTW haven't looked at the output of describe.. yet)

Coehn

Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

But there is no need for analyzing code to just get the message and backtrace. Simply call master()->describe_error().

__________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken.

The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________

Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

Yes, it only handles Errors and arrays.

But anything can be thrown with throws. So the method handles just 2 possibilities of a wide range. Not even considering custom classes and array (formats/'buildups')

But you are suggesting that it should only handle Errors?

Yes, so there's no need for a master->describe_error. No need to distinct between Error and array and possibly anything else that is returned as an error related object.

Not much of an improvement.

Problem is; anything can theoretically be thrown. You have to take this in account when handling an error related object. It's not always an Error or array. If it were always an error, you can allways handle it the same way and possibly in a later stadium differ between kinds/types of error classes thrown.

Instant access to error message: ((array)e)[0] Instant access to backtrace: ((array)e)[1]

But yes, it would be nice if more builtin errors were objects instead of arrays.

That's exactly what I mean :) Always return an Error object which has something like the following members:

string message array(string) stacktrace or even array(Trace) stacktrace (Trace containing path/obj/linenumber/ident/whatever) mixed additionalSomething

Coen

__________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken.

The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________

But still, I hardly write all the code I use myself.

And then again, with the current situation I still have to take into account the 2 options when handling an error, _every_ time I handle an error. I still think this causes more overhead than necessary. For instance if I just want to display the error message and nothing else.

Of course, if pike had something like static methods, I would create one method for handling errors and use that. But FAFAIK this isn't possible.

Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

The two possibilities "Error" and "array" are the only ones which can occur "spontanously". You will never get anything else unless you throw something else yourself. So it's basically a case of "don't do that then". It's up to the application if you want to use strange throw values or not.

__________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken.

The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________

...

The two possibilities "Error" and "array" are the only ones which can occur "spontanously". You will never get anything else unless you throw something else yourself. So it's basically a case of "don't do that then". It's up to the application if you want to use strange throw values or not.

But still, I hardly write all the code I use myself.

And then again, with the current situation I still have to take into account the 2 options when handling an error, _every_ time I handle an error. I still think this causes more overhead than necessary. For instance if I just want to display the error message and nothing else.

If what you are requesting is backwards incompatible changes to throw and/or catch, you will hardly meet much approval here. It is, however, widely agreed upon that current exception handling in Pike has _a lot_ of improvement potential (the gentle way of stating that it sucks, and that we agree it is substandard to what many other languages offer).

One of the current system's big warts is, as you note, that the code you have to write to catch errors you did not plan for receiving, and inspect or process their data, _smells really bad_. Ways forward from that are of course of general interest, and good ideas about how to tackle that issue will probably be well received. (If you are content with a single method that converts random errors to a human readable string, describe_error might be enough for you.)

I believe that, regarding improvements and behaviour changes to the raw throw/catch construct, most of the pike core developers now have rather high standards for what will be good enough to be implemented, if we do change them -- which means that kludges to them to make the status quo feel slightly less bothersome will likely not meet much approval here, nor exert any changes to happen spontaneously.

If you want to improve on the status quo, coming up with some nice support method or class to put in the Error module might be a good spot to focus your attention on, so you could write code similar to this, perhaps (and I don't claim it's good design; just a possible starting point for further discussion and improvements):

Error e = Error.inspect(catch(...)); // returns falsity for catch()=>0 if (e) { if (has_prefix(e->message, "Division by zero")) { // ... } // other goodies you want to see conveniently available - and how }

And, while that suggestion too has all sorts of flaws, I think it is a better starting point than your present line of enquiry; discussion does not seem to move forward anywhere productive.

On Fri, May 09, 2008 at 02:25:03PM +0200, Johan Sundstr�m (Achtung Liebe!) @ Pike (-) developers forum wrote:

Error e = Error.inspect(catch(...)); // returns falsity for catch()=>0

in 7.7 there is already an Error.mkerror() function which does pretty much just that.

it was added after i stumbled over the same problem of wanting to avoid having to write complex checks for a catch result.

it currently only detects e->is_generic_error, and wraps everything else into an Error.Generic which could probably benefit from some improvement in case there are Error classes that don't inherit Error.Generic (although having one base class for all errors makes things easier)

greetings, martin.