+1 Still missing in P9... have to return errors from other espace actions which can get messy.

Would appreciate this a lot!!! +1

I still want this!  It makes it a lot harder to catch an Exception coming from a module you are using.

Still missing it... We have a common exception handler but we don't have the change to raise the exceptions that we predicted on that module...

I also have a need for it. Now work around with a public static entity with ExceptionTypes.

I would also like to see this feature.

I need this feature.

I'm currently in need of this exact feature.

I have a webservice which throws an exception if input is incorrect, response is empty, or index is out of range, I want these different exceptions to be handled differently within other espaces where I use said webservice, however currently I can only use the ALL EXCEPTIONS handler and within it a switch with every possible exception I have.

It would be so much easier if I could just reference exceptions from another module.

It would be really interesting to hear OutSystems' thoughts here - to me this seems like an essential feature, and yet this idea has apparently been sitting here for 7+ years. Maybe I am misunderstanding something about how I should handle exceptions in OutSystems?

02-02-2018

Outsystems how about some update on this? :) 

+1

This will be very useful. Outsystems please add this feature.

+1 

We definitely need this :)

Please, please, please :)

In a nutshell, Exception handling in OutSystems sucks in a relly big way! Exceptions should be public, should be a part of the module's API just like actions, roles or entities... 

User exceptions available only within the same module? No way! We need to handle them from consuming module.

+1

We need this feature urgently, it does not make sense to have the possibility to reference several module objects and not be able to reference exceptions or make them public in some way that can be centralized at some point in the handling of errors.

Duplication of exceptions for the same purpose in different modules is a TERRIBLE practice.

Please, it's is a huge limitation on OS.

Seriously consider make it better.

I have referenced this idea on a more broad scenario where it's part of a set of limitations that block each other.

https://www.outsystems.com/ideas/6943/add-exception-handling-on-exposed-rest-api

Please consider remove some os this blocks.

Márcio.

9 years, still 'on our radar'...

It feels fairly standard to want to bubble an exception up to a higher level, especially if your application is structured into 4 layers as advised. The extremely poor exception handling is one of Outsystem's largest flaws that I have encountered so far.

Come on OutSystems, we developers need this really bad! Currently, handling exceptions between different modules is a pain in the ass!

Even worst is the fact remembered by Daniël about can't copy/past and when updating a cloned espace the merge window cannot bring these exceptions during merge, resulting in many errors to be manually fixed after merge. With the need to open two or more versions side by side to see what exceptions were missing, and creating one by one, and in each use of the new exceptions we need to fix the message. Very annoying limitation.

This still makes a lot of sense. Mapping exceptions to Success flags or other methods to "translate" exceptions between modules is really tedious and error-prone. 

Any updates on this being implemented?

Yes, it will be helpful. 

Well,

the idea is coming up on it's 11th birthday this spring (what was that, Outsystems 7 ?) so I wouldn't hold my breath.

Not really sure why this is not available yet. It is standard in so many OOP languages to have exceptions that can be bubbled up with their specific type and not just a generic type like AllExceptions type.

And it shouldn't be that hard, we are waiting for it ;)

It shouldn't be hard, but I bet the business value is quite low, so...

Maybe not directly measurable business value, but a platform must satisfy more requirements than just business value.

The last couple of months i was bombarded on linkedin with Outsystems commercials about how good they are for tackeling technical debt, fixing this type of platform shortcomings would fit right in that story.

Agree. Developers are also consumers of the technology and the better the tool in tackling complex tasks the more the development community will acept the tool. I know of quite many delayed projects due to lack of developers. So pleasing devs does also have its own business value. Many of us take pride in producing working quality software based on elegant solutions, and the maturity of the dev technology used has a big impact in this regard. ;)

Hi guys, 

I have been following this ideia for some time and on the last notification I got I thought, Why not use the forge to create a temporary solution while this is not available on Service studio. 

So I created the following component GExceptions which is still in development. Please feel free to comment or discuss. 

Pedro -

I took a look at it, and it's nice to see the effort put forth to try to solve the problem, but it doesn't really solve the problems. I could go into some detail if you'd like, but as an example, because the consuming code can't differentiate well between a "GUserException" (because we don't have public exception lolol) and any other non-system Exception, the CatchException action doesn't help us. It also means we need to use Switch widgets in Exception handlers looking at string literals to decide how to handle the output, which is a complete non-starter. My suggestion would be, at the very least, to have applications "register" exceptions in a bootstrap from static entities (or something similar), with a unique ID, and be able to use that, so that this way they aren't juggling strong literals in every exception handler in the app. I also suspect that this will mess with transaction management in the cases where you don't want to abort transactions, though I'd have to use it in a real world scenario to verify that.

J.Ja

Hi Justin,

Thanks for your comment, and Yeah I agree that it is a bummer not being able to directly catch the correct exception, but the ideia is to catch the exception using the Outsystems exception handler,  call the "CatchException" action from the module which returns a "GUserException", that has a unique ID which can be used to determine the paths on the switch module, and therefore you would not be comparing strings. 

For the transaction handling part, yeah that would be the most challenging part, because since all the GUserExceptions are basically a subset of Outsystems User Exceptions, on the "Exception Handler" Node for the user exception or you either "Abort" or not for all. 
Still this could be worked around if we just set "Abort Transaction" to no on the  OS Exception handler and then in the logic where the switch is you could call "AbortTransaction" action if that particular "GUserException" required it to do so. 

EDIT: Maybe adding this part about the handling of transactions on the component documentation would be a good ideia.

Pedro -

Yeah, I see how it works, but my concern is that the Switch on each Exception Handler is going to have a lot of logic looking like:

CatchException.ExceptionName = "ValidationException"

Which means that if you ever change the exception name, you need find every use of "CatchException" and inspect to see if it checks for "ValidationException". This is why I suggest using a registration system of exception names, so the applications can map their types to a unique ID that will never change (such as a GUID).

J.Ja

The way it was designed was to use the ids and not hardcoded names , so actually the comparations would be something like : 

CatchException.Exception.UserExceptionId = Entities.UserException.ExampleException

Pedro -

Oh, I see. You wrote this the same way I originally wrote my configuration system in Application Framework, which turned out to be a big problem. It means that the only way to use this is to edit the module itself... which means it can't be upgraded from the Forge. This is why I had to switch to a registration pattern, so that the actual component could be upgraded from the Forge. It also properly separates the component itself from the logic of the consumers.

J.Ja

Justin, yeah that was one of my concerns while developping it, but I couldn't find an easy way to allow the customization of the records without editing the module directly for the time being. I'll look into that registration pattern tomorrow. 

Thanks for your feedback!! 

Pedro -

Glad to help! Download "Application Framework" off the Forge, and look at how the Security and Configuration modules work, to get an idea of how I handled it. I don't like writing this kind of code, it makes it harder for the consuming developer to use, requires a lot of documentation, depends on bootstraps, and is more work for me... but there doesn't seem to be an alternative. :(

J.Ja

Yeah, we need this feature

It's surprising that after 10+ years, this feature has not been implemented, as it could greatly simplify the process of maintaining exceptions across multiple modules, particularly in larger solutions. 

Is there any proper workaround to handle this scenario? 

The only thing i can come up with is not something i would call proper.

You would have to add some logic to the exception message to explain what type of error it is:

ExceptionMessage: "ValidationException|blablabla"

And perhaps create a module to maintain these kind of exceptions.

For me it is not worth the effort, but i am still eagerly waiting for this feature. 

A definite must!

There is an ugly workaround: you can create a public Role and use its exception, instead of creating a User Exception. The exceptions defined under a Role are already public and you can explicitly raise them in a producer, and handle them in a consumer module. Interesting that this feature already exists, but is not made available for User Exceptions where they would be most valuable...

I would use this only as a last resort, and use a naming convention for these roles to signal that they are not meant for access control.

Also keep in mind that, by default, these exceptions are handled by the global exception handler and cause a redirect to InvalidPermissions screen.

For example, we have used this mechanism to signal that a user session is invalid (not due to an invalid login or lack of roles, but due to business rules). In that case, we could use the Not Registered exception, which can be raised in a producer module, and caught in a consumer module.