Opened 13 years ago

Closed 13 years ago

#1410 closed defect (fixed)

dojo.raise Swollows Exceptions and Reports in browser when debug is false.

Reported by: ole_ersoy@… Owned by: Adam Peller
Priority: high Milestone: 0.9
Component: General Version: 0.3
Keywords: Cc:
Blocked By: Blocking:

Description

This is with reference to Ticket #1388 (defect)

Background/Discussion?:

I want exceptions to stop execution.

That's easy, throw new Error('Whatevva error'), does that.

However, I can't customize the message with further info details from the objects that caused the error.

So I thought AHA! dojo.raise lets me do that - HAHA!

So now I can create my own exception, and throw it with dojo raise.

However, dojo.raise swollows the exception. DOH!

Also, dojo.raise still reports the exception in the browser even when debug is set to false and when I'm catching the thrown exception.

Change History (5)

comment:1 Changed 13 years ago by Adam Peller

Owner: changed from anonymous to Adam Peller

Good point. Should we be rethrowing that exception instead of Error(message)? I'd say yes.

Also, dojo.raise still reports the exception in the browser even when debug is set to false and when I'm catching the thrown exception.

See ticket #264. No obvious solution.

comment:2 Changed 13 years ago by dylan

Milestone: 0.5

comment:3 Changed 13 years ago by ole_ersoy@…

How about first letting Dojo support specific exception types / hierarchies like with Java.

Except these would not be throwable exceptions. Their primary reason for existance would be more along the lines of a "Marker Interface" pattern, thus they exist only for the sake of providing additional type information.

So an exception could be defined like this:

dojo.declare("dojo.presentation.ValidationException?",

SomeGeneralDojoExceptionOrAnExceptionSpecificToSomAPIDomain,

{

type: 'ValidationException?',

message: 'This message should be set when the exception is thrown'

Note that the type and message properties should really be defined on the parent exception and ultimately on the root Exception of the dojo exception hierarchy.... }

OK - so now when I want to throw an exception I first create on like this:

e = new dojo.presentation.ValidationException?();

e.message = "The object: " + someObjectWithSensibleToString + "does not exist";

dojo.raise(e);

instead of throwing Error('Completely Fixed Message');

dojo.raise now uses the exception and throws it with an appropriate error message.

So dojo.raise()'s job is to customize the error message that is put in the Error object that is thrown.

so it does inside dojo.raise we have

throw new Error(customDojoMessage);

and customDojoMessage could be something like:

customDojoMessage = 'An exception of type' + 'e.type was thrown. Info: ' + e.message;

I think that's all dojo.raise should be responsible for.

If the object should provide additional logging or reporting, then the appropriate api should be used...or dojo.raise could support a flag that if true, will call the reportin/debugging/logging api.

BTW - Is the specific service / contract that the dojo api methods support documented and unit tested?

I think it would be a good idea to have a standard around that, with some simple cookbook examples on how to do it. I'll put some examples in when I submit the dojo.presentation framework for review.

comment:4 Changed 13 years ago by Adam Peller

I like the logging idea -- I think dojo.raise() would be an excellent point to trap and log the fact that an exception was raised

For now, we're going to keep it simple. I think the Java exception pattern of creating deep OO hierarchies is too heavy for Dojo -- I don't even think it's used effectively in Java most of the time, frankly.

comment:5 Changed 13 years ago by Adam Peller

Resolution: fixed
Status: newclosed

(In [5779]) Change dojo.raise() to rethrow exception, only print FATAL "exception raised" message for isDebug. Fixes #264 and #1410

Note: See TracTickets for help on using tickets.